FAQ

Can I interact directly with the development team?

Yes! Our development team would love to learn more about you and your use case. To get in touch, you can join us on Slack.

1. Request an invitation to the workspace by entering your email.
2. Check your email for an invitation.
3. Click Join now to go to the sign-in page.
4. Create an account by entering your name and a password.
5. When you're in, search for the channel #appid-at-ibm.
6. Join the channel.

Welcome! Now that you're up and running, feel free to ask questions, give feedback, and help others.

Using the Slack channel is not a replacement for opening a support ticket. If you encounter a more serious issue, issues with IBM Cloud that don't relate to App ID, or need to share more information than you are comfortable sharing in a public forum, open a support ticket.

Why do I need to allowlist my redirect URI?

A redirect URI is the callback endpoint of your application. When you allowlist your URI, you're giving App ID the OK to send your users to that location. At runtime, App ID validates the URI against your allowlist before it redirects the user. This process can help prevent phishing attacks and lessens the possibility that an attacker is able to gain access to your user's tokens. For more information about redirect URIs, see Adding redirect URIs.

Do not include any query parameters in your URL. They are ignored in the validation process. Example URL: http://host:[port]/path

How does encryption work in App ID?

Check out the following table for answers to commonly asked questions about encryption.

What clock synchronization does App ID use?

App ID runs in IBM Cloud, which uses an internal NTP server: servertime.service.softlayer.com.

Synchronizing your application with App ID's time source depends on which environment that you're using to run your application.

• If your application is running in IBM Cloud Classic Infrastructure, set your NTP servers to servertime.service.softlayer.com.
• If your application is running in IBM Cloud VPC Infrastructure, set your NTP servers to time.adn.networklayer.com.
• If your application is not running in IBM Cloud, you do not have access to these time servers. In this case, set your NTP servers to time-a.nist.gov or time-b.nist.gov.

What is the difference between App ID and Keycloak?

Both App ID and Keycloak can be used to add authentication to applications and secure services. The main difference between the two offerings is how they're packaged.

Keycloak is packaged as software, which means that you, as the developer, are responsible for maintaining functionality of the product after you download it. You're responsible for hosting, high-availability, compliance, backups, DDoS protection, load balancing, web firewalls, databases, and more.

App ID is a fully managed offering that is provided "as-a-service". This means that IBM takes care of the operation of the service, handles compliancy, availability in multiple zones, SLA, and more. App ID also has an integrated experience with the IBM Cloud Platform that includes native runtimes and services such as the Kubernetes Service, Cloud Functions, and Activity Tracker.

Can I use the same client ID in more than one application?

While you technically _can_ use the same credentials in more than one application, it is highly recommended that you do not for several reasons. Foremost, because when you're sharing your ID across applications any type of attack or compromise then affects your entire environment rather than one application. For example, if you're using your ID across three applications and one of them becomes compromised, all three are then compromised. An attacker is able to impersonate any of your apps. The second reason is that when you're using the same client ID in multiple apps, there is no way to differentiate between applications. For example, you're unable to tell which app was used to generate a token.

How can I update my application to use a new service instance without losing any data

You can migrate the information in one instance of App ID to another.

1. Create an instance of the service.
2. Duplicate your identity provider configuration by using the GUI.
3. Migrate your user profiles. Known users are exported as a JSON object. Anonymous user's cannot be migrated. You can choose to import the entire object into the new instance or break it up and divide the users as you see fit if you have more than one instance. For Cloud Directory, see Migrating users. For federated identity providers, use the following steps.
4. Create application credentials to invoke the new service instance.
   1. In the service dashboard, navigate to the Applications tab.
   2. Click Add Application and give your application a name. Then, click Save.
   3. Click View credentials in the table and copy the output.
   4. Paste your new credentials into your application.
5. Update your application to use the new credentials including any URLs.
6. Depending on your configuration, you might need to redeploy or unbind and rebind your application.

Can App ID help configure logout?

Depending on how you configure your application, App ID can help to facilitate a log out functionality for your users. Check out the following table to see where functionality for logout is available.

<script>
  var ticker = setInterval(tick, 1000);
  var counter = 5;
  function tick() {
    var timerDiv = document.getElementById("timer");
    if (counter > 0) {
      timerDiv.innerText = "Logged out. Redirecting back in " + (counter--) + " seconds.";
    } else {
      document.location = "./appid_logout";
    }
  } </script>
<iframe height="0" width="0" src="https://login.microsoftonline.com/common/wsfederation?wa=wsignout1.0"></iframe>