SSO for mobile apps with OpenID Connect

SSO for mobile apps with OpenID Connect

develop

Options for implementation of single sign-on for mobile apps.

Overview

In this article we discuss which options you have to implement SSO with OpenID Connect for mobile apps.

Learn the basics of SSO

For a general overview of SSO with OpenID Connect, see Web Client SSO with OpenID Connect


The Mobile SSO process

Background

There has been an 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

overview

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. Curity 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 verifies the grant and client
  8. Curity 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 verifies the grant and client
  8. Curity 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.

Cookie Jar

WebView does not share the cookie jar with the system browser. Login will work but no SSO is possible.

Android

For more information about Android WebView options, see: webview

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.

ParameterDescriptionCommentExample
acr_valuesGoverns the allowed authentication method for SSO.Requests that Curity uses a certain authenticator (or group of authenticators). Multiple strings are separated with space.acr_values=urn:se:curity:authentication:html-form:html1
max_ageSpecifies a maximum allowed age for the SSO session (in seconds)If the session is older, the user is prompted to login again.max_age=300
promptLets the authentication server know that login should be required.Allows for the client to force new authentication.prompt=login

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


Was this page helpful?