Mobile Connect is a mobile centric solution that aims for MNOs (Mobile Network Operator) to become a trusted identity service provider to third party providers. However, Mobile Connect is not only a new way to authenticate users in the mobile network. Moreover, it provides a way to link the digital and real identity of a person and protect their data, giving them back the control for sharing this information when, where and who with.
MobileConnect takes advantage of the MNO assets such as the mobile device and the SIM card. Thanks to these assets the MNO can almost always reach the user and send a challenge to authenticate them. In that way, the user’s device turns into a kind of addressable support that keeps the user identity that in turn can be validated by means of different authenticators or different ways to authenticate the user.
These different ways to authenticate users provide different validation security levels. This is the so called Level of Assurance (LoA) that describes the degree of confidence in the authentication process. In short they provide certain assurance that the user who is being authenticated is who they claim to be.
 |
| Mobile Connect Logical Architecture (Telefonica Implementation) |
Note that Mobile Connect is an interoperable solution. Therefore it must work with any MSISDN from all the MNOs onboard in the Mobile Connect ecosystem. This is accomplished using a discovery process that occurs in a previous phase to the authentication process. The aim of the discovery process is to find the Identity Provider the MNO user belongs to, and redirect them to the MNO Mobile Connect implementation.
The figure above shows a very high level architecture of the Telefónica Mobile Connect system, but it does not give us too much information. It seems that there are a set of boxes that you can combine and voilá! you have an implementation of Mobile Connect, well… It is a no brainer that it cannot be so easy, right?
Don’t worry, in the next section we are going to try to explain the main functionality of each component in the architecture and its role in the mobile connect authentication process flow.
Telefónica Mobile Connect Architecture
Our Mobile Connect implementation is based on a set of microservices that in turn make up larger components or subsystems which each have a specific role (see figure above).
You can distinguish three main functionalities in Mobile Connect:
- The Identity Gateway, the brain of Mobile Connect, offers the interface for the Service Providers to be integrated in Mobile Connect.
- The Authenticators, provide user validation.
- The Data Gateway gives the user’s attributes.
Mobile Connect interface to Service Providers follows the Authorization Code Flow of the OpenID Connect protocol, where Service Providers act as the RP-Relay parties in the OIDC protocol.
 |
| Abstract of the OpenID Connect protocol steps |
Identity Gateway (ID)
The Identity Gateway (aka ID-GW) server is a component that can be broken down into a set of individual components. These components meet the functionality of Identity and Access Management along with the functionality to control and protect the resources that show the attributes that can be shared.
OIDC AuthServer
It is the core component that implements the OpenID Connect protocol as per the OIDC Mobile Connect Profile. It shows the Authorization and Token endpoints. It receives the authentication request, checks if the client (service’s app) is allowed to request the claimed scopes and, in such event it sends the request to the authenticator selector. In addition, in the case of successful authentication, it generates the authorisation_code and the access_token, along with the id_token server.
Authenticators Routing Subsystem
This component is called by the OIDC server during the authentication process. It selects the right authenticator based on the context in the request (e.g. LoA), routing policies, etc. and prompts the user to provide their credentials where appropriate.
Token Manager
This component creates the id_token, access_token and the authorisation_code in the auth_code flow. It also offers an API to query the information associated to an access_token.
Access Gateway
The Access Gateway shows the UserInfo endpoint. It aims to protect access to the real UserInfo resource showed by the back-end. The Access Gateway acts as a proxy that receives the request from the service provider, checks the access_token against the Token Manager to determine the client granted scopes. If the client has the necessary scopes to access the requested resource and the request upper limit has not been reached (traffic throttling), the Access Gateway routes the request toward the Data GW providing the granted scopes.
Provision
This component offers an API to provide any data that the ID-GW needs to carry out the different tasks for which it is intended to: the scopes, products (set of scopes for different grant types), devs, apps and APIs.
Users
This component shows an HTTP REST API to manage the provision of the Mobile Connect users. It will be used to register, update users, etc.
Authenticators
These components represent an abstraction layer that allows the ID Gateway subsystem to talk to the different authenticators in the MNO. All the Mobile Connect authenticators are Mobile Centric authenticators, that is to say, all of them authenticate the end users interacting with their Mobile phone.
 |
| Authentications using Mobile Connect SMS+URL |
In the next few paragraphs we describe some of the most common authenticators used in Mobile Connect, taking into account that a big list of them can be integrated in the solution.
SMS based authenticator
SBA sends a SMS to a mobile phone number. This SMS should have a code (OTP), a link or both in order to authenticate the user.
- OTP: sends an One Time Password in the SMS that must be validated in the form entry.
- URL: sends a URL in the SMS that must be clicked by the user to be authenticated.
- OTP+URL: sends an OTP together with a URL. The user can submit the OTP in the form entry or click the URL to be authenticated.
MSSP (Mobile Signature Service Provider)
This component is the server side of the SIM Applet based authenticator. It can deal with both LoA2 and LoA3 authentications, by sending a challenge using a “class 2” binary 3.48 SMS to the end user’s SIM. This message reaches the SIM directly without any possibility to be intercepted by any application in the mobile phone.
Then the SIM wakes up an applet asking the user for consent using “click-ok” or by a PIN/Personal Code. Once user verification is done, the applet returns an authenticated response back to the MSSP. The MSSP validates the response and gives back success or error. It is worth it to point out that all messages between the MSSP and the SIM are end-to-end encrypted.
FIDO Authenticator
This component implements a FIDO Server authenticator which will send a challenge to authenticate the user by a biometric authenticator in their mobile phone.
Remark: these are some of the authenticators that can be used to authenticate user in Mobile Connect. However, as one of the key requirements of Mobile Connect is to be able to authenticate the end user irrespective of the underpinned authenticator, it needs to have a flexible way to integrate the ID-GW with the different kind of authenticators that show different APIs in turn. To achieve this objective, an adaptor (based on redirections) has been built per every authenticator to communicate it with the ID-GW.
Data GW (Data Gateway)
This component will be connected to the different sources in the MNO or to potential 3rd parties. It gathers all the attributes that will be showed in the UserInfo endpoint and probably other future info endpoints with extra information.
