Mobile applications

OIDC/OAuth is designed to work well with mobile applications.

Typically the application will initiate login opening the system browser so that the user can enter credentials. Once the OIDC/OAuth flow has completed, Feide issues the ID token and access token and send them back to the mobile app.

The app will use the access token to look up further information about who the user is, and maybe communicate with its backend using Feide data sharing.

Best current practice is to use authorization code flow with PKCE. Implicit flow is less secure, and no longer recommended.

Authentication

We strongly recommend that native apps use the system browser for the OIDC/OAuth flow. Embedded web views are less secure, and should not be used. The system browser can often be opened as an in-app browser tab, and this usually gives the best user experience. iOS has supported this since late 2015 (iOS 9), Chrome on Android since 2016 (Chrome 45).

The native app must be reachable locally at a URL. The leading mobile operating systems now allow apps to claim https URIs in the domains they control, so that these URLs are opened in the app instead of in the browser. iOS and Android have supported this since late 2015 (iOS 9 and Android 6.0). Where available, this is the preferred mechanism. Register the redirect URI in the same way as for any other OIDC/OAuth client.

To support older operating system versions, a custom URL Scheme for the native app must be used, such as no.mycompany.mydataportenapp. Best current practice mandates the reverse domain name pattern shown here. It reduces the risk of collisions, and if they occur, makes them easier to manage.

In the dashboard, register a redirect URI such as no.mycompany.mydataportenapp:/.

Then register a listener that is triggered when the app is opened with this scheme.

This IETF document describes best current practice: OAuth 2.0 for Native Apps (RFC 8252).