--- name: appid-manageidp title: Managing authentication description: Identity providers (IdP's) add a level of security for your mobile and web apps, through authentication. With IBM Cloud® App ID, you can configure one or several identity providers to create a custom sign-in experience for your users. last-updated: 2026-03-04 --- > ## Documentation Index > The table of contents for this documentation set is at https://cloud.ibm.com/docs/appid?format=markdown > The index for all IBM Cloud docs is at: https://cloud.ibm.com/docs/llms.txt > Use these files to discover more information as needed. # Managing authentication {: #managing-idp} Identity providers (IdP's) add a level of security for your mobile and web apps, through authentication. With IBM Cloud® App ID, you can configure one or several identity providers to create a custom sign-in experience for your users. {: shortdesc} App ID interacts with identity providers by using various protocols such as OpenID Connect, SAML, and more. For example, OpenID Connect is the protocol that is used with many social providers such as Facebook, Google. Enterprise providers such as Azure Active Directory or Active Directory Federation Service, generally use SAML as their identity protocol. For Cloud Directory, SCIM to verify identity information. When you use social or enterprise identity providers, App ID reads user account information. Because the service never has write access to the information, users must go through their chosen identity provider to do actions, such as resetting their password. For example, if a user signs in to your app with Facebook, and then wanted to change their password, they must go to `www.facebook.com` to do so. {: note}a When you use [Cloud Directory](https://cloud.ibm.com/docs/appid?topic=appid-cloud-directory&format=markdown), App ID is the identity provider. The service uses your registry to verify your users identity. Because App ID is the identity provider, users can take advantage of advanced functionality, such as resetting their password, directly in your app. Working with application identity? Check out [Application identity](https://cloud.ibm.com/docs/appid?topic=appid-app&format=markdown). {: tip} Several identity providers can be configured to be used by App ID. Check out the following table to learn about your options. | Identity provider | Type | Description | |-----|----| -----| | [Cloud Directory](https://cloud.ibm.com/docs/appid?topic=appid-cloud-directory&format=markdown) | Managed registry | You can maintain your own user registry in the cloud. When a user signs up for your app, they are added to your directory of users. This option gives your users more freedom to manage their own account within your app. | | [SAML](https://cloud.ibm.com/docs/appid?topic=appid-enterprise&format=markdown#enterprise) | Enterprise | You can create a single sign-on experience for your users. | | [Facebook](https://cloud.ibm.com/docs/appid?topic=appid-social&format=markdown#facebook) | Social | Users can sign in to your app by using their Facebook credentials. | | [Google+](https://cloud.ibm.com/docs/appid?topic=appid-social&format=markdown#google) | Social | Users can sign in to your app by using their Google credentials. | | [Custom](https://cloud.ibm.com/docs/appid?topic=appid-custom-identity&format=markdown#custom-identity) | Custom | If none of the provided options fit your specific need, you can configure your own identity flow to work with App ID. | {: caption="Identity provider options" caption-side="top"} ## Managing providers {: #managing-providers} {: help} {: support} An identity provider creates and manages information about an entity such as a user, a functional ID, or an application. The provider verifies the identity of the entity by using credentials, such as a password. Then, the IdP sends the identity information back to App ID, which authorizes the user and then grants access to your app. {: shortdesc} 1. Navigate to your service dashboard. 2. In the **Identity Providers** section of the navigation, select the **Manage** page. 3. On the **Identity Providers** tab, set the providers that you want to use, to **On**. 4. Optional: Decide whether to turn off **Anonymous users**, or leave the default, which is **On**. When set to **On**, user attributes are associated with the user from the moment they begin interacting with your app. For more information about the path to becoming an identified user, see [Progressive authentication](https://cloud.ibm.com/docs/appid?topic=appid-anonymous&format=markdown#progressive). App ID provides default credentials to help with your initial setup of Facebook and Google+. You are limited to 20 uses of the credentials per instance, per day. Because they are IBM credentials, they are meant to be used only for development. Before you publish your app, update the configuration to your own credentials. {: tip} ## Adding redirect URIs {: #add-redirect-uri} Your application redirects users to App ID for authentication. After authentication completes, App ID redirects users back to your application. In order for App ID to be able to redirect users back to your app, you need to register the redirect URI. During the sign-in flow, App ID validates the URIs before it allows clients to participate in the authorization workflow, which helps to prevent phishing attacks and grant code leakage. By registering your URI, you're telling App ID that the URI is trusted and it's OK to redirect your users. 1. Click **Authentication Settings** to see your URI and token configuration options. 2. In the **Add web redirect URI** field, type the URI. Each URI must begin with `http://` or `https://` and must include the full path, including any query parameters for the redirect to be successful. Need help formatting your URI? Check out the following table for some examples. | Type | Example URI | | ---- | ----------- | | Custom domain | `https://mydomain.net/myapp2path/appid_callback` | | Ingress subdomain | `https://mycluster.us-south.containers.appdomain.cloud/myapp1path/appid_callback` | | Wildcard | `https://mydomain.net/*` \n ***Note: Wildcards are not recommended for use in production apps.*** | {: caption="Example web redirect URIs" caption-side="top"} It is recommended that you always use encryption and avoid HTTP. {: note} 3. Click the **+** symbol in the **Add web redirect URI's** box. Be sure to register only URIs of applications that you trust. {: important} 4. Repeat steps one through three until all possible URIs are added to your list. ## Configuring token lifetime {: #idp-token-lifetime} {: help} {: support} App ID uses tokens to identify users and secure your resources. You can adjust your configuration to fit your applications needs by setting the lifespan of the tokens. Token lifetime begins again each time a user signs in. For example, you set your refresh token lifetime to 10 days. An access token and a refresh token are created when the user signs in for the first time. If the user returns to your app 3 days later, they wouldn't need to sign in again. But, if the user waited 12 days after their initial sign-in, and then returned to your app, they would need to sign in again. For more information about tokens, check out [Understanding tokens](https://cloud.ibm.com/docs/appid?topic=appid-tokens&format=markdown#tokens). When you set token expiration, the values apply to all the providers that you make available. If you want to customize your tokens further, try calling the API to [map custom claims](https://cloud.ibm.com/docs/appid?topic=appid-customizing-tokens&format=markdown) so that the user information is available at run time. When you work with the API, the customization times are configured differently. {: tip} 1. Go to the **Manage Authentication > Authentication settings** tab of the service dashboard. 2. In the **Sign-in Expiration** tab, toggle refresh token to **Enabled**. 3. For each token type, add a value for each token type as described in the following table. | Token type | Description | Default | Options | | ---------- | ----------- | ------- | ------- | | [Access](https://cloud.ibm.com/docs/appid?topic=appid-tokens&format=markdown#access) | The length of time for which access tokens are valid. The smaller the value, the more protection that you have in cases of token theft. | 60 minutes | Any value in the range 5 - 1440 | | [Refresh](https://cloud.ibm.com/docs/appid?topic=appid-tokens&format=markdown#refresh) | The length of time for which refresh tokens are valid. The smaller the number, the more frequently a user must sign themselves in. | 30 days | Any value in the range 1 - 90 | | [Anonymous](https://cloud.ibm.com/docs/appid?topic=appid-anonymous&format=markdown) | The length of time for which anonymous tokens are valid. Anonymous tokens are assigned to users the moment that they begin interacting with your app. When a user signs in, the information in the anonymous token is then transferred to the token associated with the user. | 30 days | Any value in the range 1 - 90 | {: caption="Token types and customization options" caption-side="top"} [Identity tokens](https://cloud.ibm.com/docs/appid?topic=appid-tokens&format=markdown#identity) are automatically configured to match the length of time that you set for access tokens. The values cannot be different. {: tip} 4. Click **Save**.