Native apps are becoming more and more part of our everyday lives. From our online purchases to instant messaging communication, native apps make certain tasks easier. However, a large number of these apps require authentication to confirm the identity of their users. Given the complexity of designing a secure authentication mechanism in web and mobile apps, several authentication protocols have been developed by different organizations to facilitate the implementation of an authentication mechanism. This is also the case with the OpenID Connect protocol.
'OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.'
From the above definition of the OpenID organization, it is clear that the OpenID Connect protocol is a successor to the OAuth 2.0 protocol. In addition to the implementation of the OAuth 2.0 authorization and authentication mechanism, which generates an access token for the access management of a third-party system, the OpenID Connect protocol integrates an identity token for managing user information in its authentication mechanism.
Authentication with OpenID Connect
Authentication with OpenID Connect can be performed with different flows depending on the type of application (mobile or web). The different possible flows are as follows:
Authorization Code Flow:
- The client application sends a request with required parameters to the authorization endpoint of the OpenID provider to obtain an authorization code. The OpenID provider forwards the user to the client application with an authorization code in the URL. The client application then sends a token request with the authorization code received to the provider's token endpoint, which sends back the tokens (ID token, access token, refresh token).
Implicit Flow:
- In contrast to the authorization code flow, the tokens (without refresh tokens) are sent back as query parameters in the URL during forwarding. The token endpoint is not required.
Hybrid Flow:
- It is a combination of the other two flows. Some tokens are sent back from the authorization endpoint and others from the token endpoint.
Taking into account the security aspect, it is noted that the forwarding URL contains the tokens as query parameters during authentication by Implicit Flow. These tokens are therefore accessible via the browser and other apps that have access to the browser. In addition, the Implicit Flow does not have a refresh token, which is required in native apps to maintain the user session by refreshing the access token.
Authorization Code Flow - the suitable variant for native apps
The authentication mechanism with the 'Authorization Code Flow' is therefore more suitable for native apps and is shown in the following figure:
In the figure above, it is observed that the native app has no knowledge of the user's credentials at all, as it is only responsible for presenting the OpenID provider's login page to the user either via an external browser application or via a WebView of the app. As soon as the user's login data has been retrieved from the OpenID provider and successfully verified, the user is redirected from the browser to the native app. During this redirection to the app, an authorization code is passed via a URI scheme. Using this authorization code, the native app can receive an identity token for authentication and an access token for authorization from the OpenID provider.
In addition to the generated access token, as with the OAuth 2.0 protocol, an identity token (ID token) and a refresh token are also generated by the OpenID provider. This identity token serves as a user ID, as it contains the user's information. The identity token is a simple JSON object generated using the JWT standard (JSON Web Token). This means that it contains a signature that must be verified before use. The refresh token serves as the master key, as it allows the OpenID provider to generate a new access token when the old one has expired. In this way, native apps can give the user the impression of remaining logged in for a certain period of time. For this reason, refresh tokens must be securely stored in the app so that no other app can access them.
E-commerce app as an example for the use of the Authorization Code Flow
For a simple and practical understanding of this protocol, a native e-commerce app can be used as an example. Given the sensitivity of the personal data used by this type of service, an authentication and authorization mechanism must be set up. Developers can choose to use this OpenID Connect protocol to avoid developing their own authentication mechanism. After configuring the management server of OpenID Connect protocol, the developers configure the management server of resources that contains the users' confidential data, such as the address, credit card information, etc. This example scenario is set up as shown in the following figure:
- App => Here is the user name: "Mueller" and the password: "Mueller-652"
- OpenID Server => The access token of user "Mueller" is "hjz74zj56*jtß06JHmbkj" and his ID token is "lgfnbn/8Gdf7568ju57 "gf8gfd5fd%rg"
- App => Give me the credit card information of the user with access token "hjz74zj56*jtß06JHmbkj"
- Resource Server => Is the Access Token: "hjz74zj56*jtß06JHmbkj" valid?
- OpenID Server => yes, it is valid. This belongs to the user with username "Mueller"
- Resource Server => Here are the credit card details of user "Mueller" with Access Token "hjz74zj56*jtß06JHmbkj" { ... }
How does OpenID Connect help developers?
In summary, the authentication and authorization mechanism of a native app using the OpenID Connect protocol simplifies the task of developers. Thanks to the tokens received from the OpenID provider, the native app can easily manage the identity of its users, their roles and the actions authorized for them.
Article by Francis Ngeukam Pamjo
