--- title: GSMA Mobile Connect description: GSMA Mobile Connect is an application of OpenID Connect that facilitates the use of mobile phones as authentication devices independent of the service provided, and independent of the device used to consume the service. component: pingam version: 7.2 page_id: pingam:oidc1-guide:oidc-mobile-connect canonical_url: https://docs.pingidentity.com/pingam/8.1/am-oidc1/oidc-mobile-connect.html llms_txt: https://docs.pingidentity.com/pingam/llms.txt docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md superseded_by: https://docs.pingidentity.com/pingam/8.1/am-oidc1/oidc-mobile-connect.html section_ids: mobile-connect-configure: Configure AM for Mobile Connect --- # GSMA Mobile Connect [GSMA Mobile Connect](http://www.gsma.com/personaldata/mobile-connect) is an application of OpenID Connect that facilitates the use of mobile phones as authentication devices independent of the service provided, and independent of the device used to consume the service. Mobile Connect thus offers a standard way for Mobile Network Operators to act as general-purpose identity providers, providing a range of levels of assurance and profile data to Mobile Connect-compliant Service Providers. In a Mobile Connect deployment, AM can play the following roles: * **The OpenID provider role**, implementing the Mobile Connect Profile as part of the Service Provider (Identity Gateway interface). As OpenID provider, AM responds to a successful authorization request with a response containing all the required fields, and also the optional `expires_in` field. AM supports the mandatory ID Token properties, though the relying party is expected to use the `expires_in` value, rather than specifying `max_age` as a request parameter. In addition to the standard user information returned with `userinfo`, AM as OpenID provider for Mobile Connect returns the `updated_at` property, representing the time last updated as seconds since the epoch. * **The Authenticator role**, implementing the Mobile Connect Profile as part of the Identity Gateway (Authenticators interface). In the Authenticator role, AM ensures that users authenticate at the appropriate Level of Assurance (LoA). A Service Provider can request LoAs without regard to the implementation, and the Identity Gateway includes a claim in the ID Token that indicates the LoA achieved. > **Collapse: LoA support** > > In AM, LoAs map to an authentication mechanism. Service providers, acting as relying parties, request an LoA by using the `acr_values` field in an authentication request. > > AM returns the corresponding `acr` claim in the ID token. > > LoA support: > > * `1` (low - little or no confidence) > > * `2` (medium - some confidence, as in single-factor authentication) > > * `3` (high - high confidence, as in multi-factor authentication) > > LoA support does not include support for `4`, which involves digital signatures. Therefore, the `dtbs` authorization parameter is not supported when requesting tokens to the authorization endpoint. Perform the steps in this procedure to set up the OAuth2 provider service: ## Configure AM for Mobile Connect 1. Configure an OAuth2 provider service in the realm. See [Configure the OAuth 2.0 provider service](../oauth2-guide/oauth2-configure-authz.html#common-task-oauth2-authz). Mobile Connect is an extension of OpenID Connect. Therefore, review the additional configuration options shown in [OpenID provider configuration](configure-openid-connect-provider.html). 2. Go to Realms > *Realm Name* > Services > OAuth2 Provider. 3. Configure OpenID Connect authentication context settings for AM to return `acr` and `amr` claims in the ID tokens. For information and examples, see [Add authentication requirements to ID tokens](oidc-authentication-requirements.html). 4. Go to Realms > *Realm Name* > Identity Stores > *Identity Store Name* > User Configuration. The user info endpoint returns `updated_at` values in the ID Token. If the user profile has never been updated `updated_at` reflects creation time. When using DS as an identity store, the value is read from the `modifyTimestamp` attribute, or the `createTimestamp` attribute for a profile that has never been modified. 5. Add the relevant attributes to the LDAP User Attributes list, and save your changes. You can now use OpenID Connect with Mobile Connect. As per the specification, you must use the Authorization Code flow to request ID tokens. > **Collapse: Supported authorization parameters** > > | Request Parameter | Support | Description | > | ----------------- | ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | > | `response_type` | Supported | OAuth 2.0 grant type to use. Set this to `code` for the authorization grant. | > | `client_id` | Supported | Set this to the client identifier. | > | `scope` | Supported | Space delimited OAuth 2.0 scope values.Required: `openid`Optional: `profile`, `email`, `address`, `phone`, `offline_access` | > | `redirect_uri` | Supported | OAuth 2.0 URI where the authorization request callback should go. Must match the `redirect_uri` in the client profile that you registered with AM. | > | `state` | Supported | Value to maintain state between the request and the callback. Required for Mobile Connect. | > | `nonce` | Supported | String value to associate the client session with the ID Token. Optional in OIDC, but required for Mobile Connect. | > | `display` | Supported | String value to specify the user interface display. | > | `login_hint` | Supported | String value that can be set to the ID the user uses to log in. For example, `Bob` or `bob@example.com`, depending on how the authentication node or module is configured to search for users.When provided as part of the OIDC Authentication Request, the `login_hint` is set as the value of a cookie named `oidcLoginHint`, which is an HttpOnly cookie (only sent over HTTPS). | > | `acr_values` | Supported | Authentication Context class Reference values used to communicate acceptable LoAs that users must satisfy when authenticating to the OpenID provider.For more information, see [The authentication context class reference (acr) claim](oidc-authentication-requirements.html#acr-claim). | > | `dtbs` | Not supported | Data to be signedAt present AM does not support LoA 4. | For access to a simple, non-secure GSMA Mobile Connect relying party sample, see [How do I access and build the sample code provided for PingAM?](https://support.pingidentity.com/s/article/How-do-I-access-and-build-the-sample-code-provided-for-PingAM) in the *Knowledge Base*.