SSO for Mobile Apps with OpenID Connect

This article, discusses which options you have to implement SSO with OpenID Connect for mobile apps.

The Mobile SSO process

Background

There has been a number of attempts to standardize and solve the challenges of securely and seamlessly enabling SSO in a mobile environment. The main challenges included:

• Absence of a unified session across applications.
• Difficulties in handling deep linking and callback URIs.
• Risks associated with secure storage and transmission of tokens.
• Friction in user experience due to external authentication redirections.
• Discrepancies in managing session and logout synchronization.

When Apple and Google announced their secure web browsers for in-app use — Android Custom Tabs for Android and ASWebAuthenticationSession for iOS — these challenges were eliminated by using the OpenID Connect standard flows. The SSO solution is based on using these web controllers to allow the user to access the shared session that exists in the System Browser. The mobile SSO solution is quite similar to how it works on a regular web application.

Example Using the Code Flow

APP A

1. The app opens a browser
2. The browser sends an authorization request
3. The user authenticates using one of the provided methods
4. The identity server sends an authorization code
5. The browser forwards the authorization code to the app and is closed
6. The app makes a back channel request with the authorization code and the client ID
7. The identity server verifies the grant and the client
8. The identity server responds with an ID Token, together with the access token and possibly a refresh token
9. The client validates the ID Token to accept the authentication

CLIENT B

1. The app opens a browser
2. The browser sends an authorization request
3. The user is already authenticated, and SSO is used
4. The identity server sends an authorization code
5. The browser forwards the authorization code to the app and the browser is closed
6. The app makes a back channel request with the authorization code and the client ID
7. The identity server verifies the grant and the client
8. The identity server responds with an ID Token, together with the access token and possibly a refresh token
9. The client validates the ID Token to accept the authentication

SSO for Mobile Apps Implementation Options

With OpenID Connect, the first session must be opened in a browser user agent, which forwards the authentication request. This limits the implementation to one of the following options:

• WebView: Running an in-app browser
• System Browser: Opening the system browser
• OS-Specific View Controller: Using an in-app view controller that shares a cookie jar with the system browser

Embedded WebView

One method to run an OIDC flow from a mobile application is to use an in-app WebView browser.

You can use the WebView to run the authorization flow and log the user in. However, the SSO will not work as the WebView does not share the cookie jar with the system browser.

For more information about iOS WebView options, see wkwebview in the Apple developer documentation. For the Android implementation, see the Android WebView documentation.

System Browser

Another robust solution is to use the system browser. It has the downside of leaving the app and opening a new tab in the system browser. The upside is that if the user has already authenticated in the browser, the login can be shared, and SSO will be applied even the first time the app is opened.

The main drawback is the impact on user experience that comes from switching from the client to the browser application.

OS-specific View Controller

As previously mentioned, both Google and Apple offer a way of dealing with the shared cookie jar problem. This is the OS-specific view controller. User experience-wise, it slides in over the app and slides out when done. It shares a cookie jar with the system browser, and the app cannot tamper with the content inside the browser.

This provides benefits such as increased security, maintaining the client experience, sharing session cookies, password autofill, and so on. This is the currently recommended way when integrating OpenID Connect with mobile applications.

Android

On Android, the recommended solution is to use Custom Tabs.

For more information about options, see Custom Tabs on the Chrome developer site.

iOS

On iOS, view controller functionality is provided by the ASWebAuthenticationSession method. This is the preferred option to provide SSO to iOS applications, in line with Apple AppStore review guidelines. Note however, that ASWebAuthenticationSession provides SSO only between applications, not between applications and the Safari browser — the cookie jar is not shared between the two.

For more information about iOS options, see aswebauthenticationsession on Apple's developer site.

SDK Integration

There are a number of open-source SDKs that implement the OpenID Connect flows for mobile applications, such as AppAuth for iOS and AppAuth for Android.They manage tokens securely, handle storage, and often provide support for authentication through the system browser.

Comparison of Implementation Options

OpenID Connect Request Parameters

A few of the request parameters specifically affect SSO: acr_values, max_age and prompt.

These parameters are optional in OpenID Connect. They allow the client to specify and modify the configured authentication behavior. You can think of them as instructions for the identity server.

Last updated: 2025-01-29

Curity