GSMA Mobile Connect vs OpenID Connect
Mobile Connect is an initiative by GSMA. The GSMA represents the interests of mobile operators worldwide, uniting nearly 800 operators with more than 250 companies in the broader mobile ecosystem, including handset and device makers, software companies, equipment providers and internet companies, as well as organizations in adjacent industry sectors. The Mobile Connect initiative by GSMA focuses on building a standard for user authentication and identity services between mobile network operators (MNO) and service providers.
Mobile Connect
Mobile Connect introduces two standard APIs: the Discovery API and the Mobile Connect API. The Discovery API enables your application to recognize the mobile network being used (either detecting by the requests generated from the mobile device itself, or asking the user to enter his/her mobile number) and whether Mobile Connect is available for that network. The Mobile Connect API allows the user to authenticate themselves using their Mobile Connect user account. For example, when you initiate Mobile Connect login via a service provider application (this can be either a native mobile app or a web app accessed either via a mobile phone or a desktop computer), the application first talks to the Discovery API to identify your mobile network operator. This Discovery API is hosted in the API Exchange, which is governed by the GSMA. Any mobile network operator (MNO) who wishes to support Mobile Connect, must register with the GSMA API Exchange. Once the Discovery API returns back the metadata related to the corresponding mobile network operator (MNO), the service provider initiates the authentication flow with the mobile network operator (MNO)’s identity provider, following the Mobile Connect API. The Mobile Connect API is based on the OpenID Connect specification.
In this post we discuss the GSMA Mobile Connect API and see how it differentiates from the OpenID Connect core specification.
Discovery API
Once the discovery phase is done, the service provider gets a valid client_id & client_secret to talk to the mobile network operator (MNO)’s identity provider along with its authorization, token and userinfo endpoints. These three endpoints carry the same responsibilities, as defined in the OpenID Connect core specification. Following lists out all the parameters, which are returned back to the service provider with the Discovery API response.
- ttl: The expiration timestamp for the discovered metadata.
- client_id: The OAuth 2.0 client_id to access the mobile network operator (MNO)’s authorization server (or the identity provider).
- client_secret: The OAuth 2.0 client_secret to access the mobile network operator (MNO)’s authorization server (or the identity provider).
The API Exchange has an on boarding process to get in mobile network operators (MNO).
- serving_operator: The name of the corresponding mobile network operator (MNO). For example, telefonica_spain, digi, telenor_norway, swisscom_switzerland, dialog_srilanka, ooredoo_qatar.
- country: The name of the mobile network operator (MNO)’s country. For example, Spain, Malaysia, Norway, Switzerland, Sri Lanka, Qatar.
- currency: The currency of the corresponding mobile network operator (MNO). For example euro, RM, NOK, SwissFranc, Rupee, QAR.
- apis: Available APIs from the mobile network operator (MNO).
- apis/operatorid: The operator Identity API.
- apis/operatorid/link[]: A collection of available links. This carries the links to the authorization, token and userinfo endpoints related to the corresponding MNO.
- subscriber_id: The MSISDN value encoded with operator RSA certificate that can be passed along as “login_hint” parameter of the Mobile Connect API.
Mobile Connect API
To authenticate the user the service provider has to redirect the user to the discovered authorization endpoint of the mobile network operator (MNO). This message exchange is defined by the Mobile Connect specification, which is built on top of the OpenID Connect specification. Even though its based on OpenID Connect, there are some differences between OpenID Connect and Mobile Connect specifications, as listed below.
- The grant type: The OpenID Connect can be used either with the authorization code or the implicit grant types (or with the hybrid flow), but the Mobile Connect must follow the authorization code grant type (set the response_type to code in the request to the authorization endpoint)
- acr_values: According to the OpenID Connect specification, acr_values is an optional parameter. But in the Mobile Connect specification its a mandatory parameter. The acr_values parameter in the Mobile Connect request is an indication of what authentication methods to be used by the identity provider. The authentication methods to be used are linked to the level-of-assurance (LOA) values passed in the acr_values parameter. The level-of-assurance, as defined by the by ISO/IEC 29115 standard, describes the degree of confidence in the processes leading up to and including an authentication. It provides assurance that the entity claiming a particular identity, is the entity to which that identity was assigned. During a Mobile Connect authentication request, the service provider specifies the degree of confidence that is required in the returned (asserted) identity, via the acr_values parameter.
The ISO/IEC 29115 standard defines four assurance levels. Only level-2, level-3 and level-4 are applicable for Mobile Connect and at the moment it does not support level-4.
- state: According to the OpenID Connect specification the state is not a mandatory parameter, but a recommended one. The Mobile Connect specification mandates using state parameter in the Mobile Connect authentication request.
- nonce: The nonce is an optional parameter according to the OpenID Connect specification, but the Mobile Connect specification has made it mandatory.
- dtbs: This is an optional parameter introduced by the Mobile Connect specification.The value of the dtbs parameter specifies the data to be signed by the private key owned by the end-user.
Once the service provider gets the authorization code from the identity provider, it can talk to the the discovered token endpoint corresponding to the mobile network operator (MNO) to get an id_token and an access_token. The request and response parameters in this flow are defined in the same way both in the OpenID Connect and Mobile Connect specifications.
The parameters in the id_token (returned from the token endpoint) has the following differences under the OpenID Connect and Mobile Connect specifications:
- sub: The sub parameter is defined as a mandatory parameter both in the OpenID Connect and Mobile Connect specifications. According to the OpenID Connect specification the sub parameter represents a locally unique and never reassigned identifier within the identity provider (issuer) for the end user, which is intended to be consumed by the service provider. The Mobile Connect specification further extends this definition where the mobile network operator (MNO) has to include a Pseudonymous Customer Reference (PCR) as the value of the sub parameter. The PCR is unique to each application and user combined.
- auth_time: The auth_time parameter represents the time of the end-user authentication. This is an optional parameter under the OpenID Connect specification but has made mandatory under the Mobile Connect specification. Under OpenID Connect this is only mandatory when a max_age request is made or when auth_time is requested as an essential claim.
- nonce: The nonce parameter represents an opaque string value to associate the service provider session with the ID Token, to avoid the replay attacks. The nonce value must be the same as the nonce used in the authorization request. This is an optional parameter under the OpenID Connect specification but has made mandatory under the Mobile Connect specification.
- acr: The acr parameter represents the authentication context class reference. It’s a case sensitive string, representing the fact that the authentication process followed the acr requested or not (in acr_values). This is an optional parameter under the OpenID Connect specification but has made mandatory under the Mobile Connect specification.
- amr: The amr parameter represents the authentication methods references. An array of case-sensitive strings to indicate the authentication method used. The values need to be negotiated offline. This is an optional parameter under the OpenID Connect specification but has made mandatory under the Mobile Connect specification.
- azp: The azp parameter represents the authorized party — the party to which the ID Token is issued. Represented as the client_id of the party. This is an optional parameter under the OpenID Connect specification but has made mandatory under the Mobile Connect specification.
- dts: This is a new optional parameter introduced by the Mobile Connect specification. The dts parameter represents the data signed with the user’s private key. If the dtbs parameter is present in the initial request, then this becomes a mandatory parameter.
- dts_time: This is a new optional parameter introduced by the Mobile Connect specification. The dts_time parameter represents the time of signing. It’s represented as the number of seconds from 1970–01–01T0:0:0Z as measured in UTC until the date/time specified. If the dts parameter is present in the response then this becomes a mandatory parameter.
- upk: This is a new optional parameter introduced by the Mobile Connect specification. The value of the upk parameter represents the end user public key. If the dts parameter is present in the response then this becomes a mandatory parameter.
Once the service provider gets the access_token and the id_token in the response from the token endpoint of the mobile network operator (MNO), it can then access the userinfo endpoint (discovered earlier via the Discovery API) of the mobile network operator (MNO). The userinfo endpoint under the Mobile Connect carries the same definition and the responsibilities as defined under the OpenID Connect specification. The OpenID Connect specification defines two ways to request claims from the userinfo endpoint: requesting claims using scope values and requesting claims using the claims request parameter. The definition of the scope values defined in both the specifications carry the same meaning.
WSO2.Telco
WSO2.Telco is a GSMA approved Mobile Connect technology provider, helping mobile network operator (MNO)s to deploy Mobile Connect with zero friction. WSO2.Telco’s platform enables accelerated integration of Mobile Connect authenticators which are exposed via REST APIs, providing the ability to both monetize identity services and leverage the same mobile network operator (MNO) network services for additional digital business opportunities. The Mobile Connect support of the WSO2.Telco is powered by the WSO2 Identity Server.
