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.
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
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
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).