SSO for Mobile Apps with OpenID Connect

Overview

In this article we discuss 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 SSO problem for mobile applications. These all converged into using the OpenID Connect standard flows when Apple and Google announced their secure web browsers for in app use. Chrome custom tabs for Android and ASWebAuthenticationSession for iOS. 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. With this the solution is quite similar to how it works on a regular web application see Web Client SSO with OpenID Connect.

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 Curity 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, including the Client ID and a secret
7. Curity Identity Server verifies the grant and client
8. Curity Identity Server responds with an ID Token, together with the access token and 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. Curity 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, including the Client ID and a secret
7. Curity Identity Server verifies the grant and client
8. Curity Identity Server responds with an ID Token, together with the access token and refresh token
9. The client validates the ID Token to accept the authentication

The 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 three 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 cookie jar with the system browser

WebView

One method to provide the browser is to use a in-app WebView browser.

iOS

For more information about iOS WebView options, see: uiwebview, or wkwebview in the Apple developer documentation.

You can choose from two different WebView technologies, the older more lightweight UIWebView and the newer, more capable WKWebView. However neither will work for SSO since they don't share cookie jars with each other.

System Browser

A robust solution is to use the system browser. It has the obvious downside of leaving the app and opening a new tab in the system browser. The upside is that if the user already has authenticated in the browser, for example for a website, 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 the article mentions in the ingress, both Google and Apple introduced a new way of dealing with the shared cookie jar problem a few years ago. This is the OS Specific View Controller. User experience wise it slides in over the app and slides out when done. It shares 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 a Chrome Custom Tab.

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

iOS

On iOS, view controller functionality is provided by the ASWebAuthenticationSession method.

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

OpenID Connect Request Parameters

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

They are optional, but by passing these parameters, the client can specify authentication and modify the configured authentication behavior. You can think of them as instructions for the authentication service.

SDK Tools

There are a number open source SDK's that implement the OpenID Connect flows for mobile applications. The one Curity recommends is AppAuth see links below

AppAuth for iOS

AppAuth for Android

Published: 2019-03-14

Curity