What OpenID Connect authorization flow to authenticate mobile app users?

Question

I am building a cross-platform mobile app that interacts with a RESTful API, and I want to use OpenID Connect to authenticate my users. I will be building my own OpenID Connect provider server.

OpenID.net claims that:

OpenID Connect allows for clients of all types, including browser-based JavaScript and native mobile apps, to launch sign-in flows and receive verifiable assertions about the identity of signed-in users.

However, I can't find any documentation explaining how to actually authenticate for a mobile app client.

This StackExchange answer makes it clear that OpenID Connect does not support the "resource owner password-based grant" flow or the "client credentials" flow.

That just leaves the "authorization code" flow (normally used by server-side apps) and the "implicit grant" flow (normally used by client-side apps). Both of these seem to rely on redirecting the user to the provider's authorisation endpoint, and having the provider redirect back to the client URL. I don't see how this can apply to a mobile app.

Can anyone explain to me (or even better, point me at a tutorial or some example code) which explains how to do this?

Update

To clarify: OpenID Connect relies on the client redirecting the user to the Authorization Endpoint, and then the provider redirecting the user back to the client. In the case where the client isn't a web app, how can this work?

Lifton

If OpenID Connect is just an OAuth 2.0 extension, I guess that the resource-owner credentials grant can still be implemented by the authorization server as a part of the OAuth 2.0 specs ? once the mobile app has an access token, I don't see anything in the OIDC specs that would forbid the app from accessing the user info through the UserInfo endpoint. – Candlepin

see #24047547 – Candlepin

A complete tutorial with latest best practises is available here medium.com/klaxit-techblog/… – Pollitt

Answer 1

Mobile apps, at least on iOS and Android, can register custom URL schemes so that a redirect from a browser can send the user back to your app along with some query parameters.

So, you can use these flows in a native mobile app, but it involves sending the user to a web browser (either an external browser app or a web view built into your application) in order for them to authenticate with the OP.

A complete article presenting how to implement the "Authorization Code Grant" flow securely on a native mobile app is available here : Building an OpenID Connect flow for mobile. It is based on latest IETF OAuth 2.0 Security Best Current Practice.

Please also note that the use of the "Implicit Grant" flow is now highly discouraged.

Provenance

Thanks James. I think you're right, in my case since it's my own app, OIDC isn't the right tool for the job. – Lifton

Do not forget that 3rd party frameworks used in the 'trusted/own' app can potentially access credentials entered by the user. Use SFSafariViewController approach, which provides the convenience for the user (i.e. staying within the app) and security (app cannot see the credentials entered) plus it provides SSO if there are multiple apps/sites. – Mimosaceous

Answer 2

I think that the Hybrid flow from the OpenID Connect spec is probably the one which you want to use. OpenID Connect Core Spec.

This does rely upon having a configured return URI, but as James says you would use a custom URI scheme to enable the mobile OS to redirect after login to your own app. Your app would then have an access code which it can use to obtain access tokens as needed (assuming that you are using Oauth2 to protect your back-end API services which the mobile app uses).

There is a vulnerability which would allow a malicious app to hijack your URI scheme and grab the tokens, There is a draft spec to overcome that Proof Key for Code Exchange by OAuth Public Clients which is worth considering implementing.

Servomechanical

According to my understanding Hybrid Flow requires the Client to have a Client Secret. This isn't really feasible in cases where the end-user controls the device running the software (e.g. mobile-apps, desktop-apps, single-page application JavaScript apps) in which case just the Authorization Code grant will suffice for mobile-apps (which can safely store a refresh_token) or Implicit Flow (for single-page application apps which cannot be trusted to store any secure state between sessions). – Gravitation

implicit flow should indeed always be used for browser based OpenID connect. PKCE which i refer to allows the apps to have a secret which prevents other apps from hijacking a response. It is, of course, perfectly possible to use implicit flow for mobile apps. – Servomechanical

Answer 3

Using an app scheme URL is the correct answer as noted above. I wanted to add additional clarification since some responses above include links to an article that makes incomplete assertions about a compliant SSO design, and make it unnecessarily complicated for a simple SSO use case. I think google's model is secure and so I might model OIDC interactions with a homegrown IDP after how theirs works.

https://medium.com/klaxit-techblog/openid-connect-for-mobile-apps-fcce3ec3472 The design in this article linked above, as depicted in the diagram on the article, does not work for google's oAuth/OIDC implementation on Android. There are two reasons for this:

1. Google will not vend any client_secret for an oAuth client that is typed "Android"
2. Suppose I switch to "Web" application which does have a secret: Google will not allow a redirect_uri other than 'http' or 'https' for an oAuth client that is typed "Web"

Instead, google officially recommends letting the typical mobile flow (and you should also be using PKCE) drop an ID Token on the client, who can then exchange it for a session with the App server: https://developers.google.com/identity/sign-in/android/backend-auth

This is secure because your IDP should be signing the JWT ID Token with a private key so it can be validated by your system's apps/services and used to assert validated (unexpired) identity intended for a particular OIDC client & audience.
** Do not pass ID Token as authorization on every request, but rather exchange it once with your backend for a secure session context as managed by your application.

Vancevancleave

Answer 4

Check out MITREid project on github:

MITREid Connect

This project contains an OpenID Connect reference implementation in Java on the Spring platform, including a functioning server library, deployable server package, client (RP) library, and general utility libraries. The server can be used as an OpenID Connect Identity Provider as well as a general-purpose OAuth 2.0 Authorization Server.

Chibcha

I'm not sure this helps. The client library is designed for a web app (c.f. github.com/mitreid-connect/simple-web-app). My question is about when your client isn't a web app. – Lifton