There are 2 common ways to include authentication in a mobile app:

1. Authentication with web based sign-in (Implicit Flow)

2. Integrating the sign-in-name and password fields into the app (Password Grant)

The second choice may be slightly simpler to implement but has security implications and more limitations: The app will have access to the user’s password, and the sign-in flow cannot contain additional steps such as Multi-Factor Authentication.

Authentication with web based sign-in

This is the typical authentication flow found on many web sites: The user clicks a login button, they are directed to a sign-in web site, and on successful sign-in they are redirected back to the app. The sign-in web site can optionally support new user registration, multi-factor authentication and other features, all of which can be configured independently of the mobile apps using the sign-in results.

Register a client

The first step is to register an OIDC client in the ID service. The essential configuration options:

• Not confidential (meaning the app will use Implicit flow, and it will not use the client secret during sign-in)

• Use a redirect URL which will direct to your app. Depending on your app platform, you might be able to use a custom URI scheme which your app has registered in the device as its own. For example: myapp://auth

You’ll receive the client ID which you will need later.

Mobile app development

You should use a library that assists in handling OAuth2 or OpenID Connect calls. Typical configuration options:

• Login flow: Implicit flow

• OIDC Configuration URI: https://your-id-server.com/.well-known/openid-configuration

• Authorization endpoint: https://your-id-server.com/openid/auth

• Userinfo endpoint: https://your-id-server.com/openid/userinfo

• JWKS URI: https://your-id-server.com/openid/jwks.json

• Client ID: The client ID you received when registering the client.

• Redirect URI: The redirect URI you have chosen for your app

• Response type: id_token (if you don’t need an access token, only user identity information) or id_token token (if you need the access token as well)

• Scope: At least openid but to include some basic profile information: openid profile email.

If needed, you can find specific URIs and supported configuration options from the openid-configuration JSON document listed above.

Register the redirect URI you chose so that it is linked to your app. For example in Android, it is registered in the app manifest. Opening that URI in a browser should then open your app and the opened activity should be able to read fragment and query parameters from the URI.

Add a button or menu from where the sign-in process starts. The button will direct the user to the authentication web page in a web browser or an integrated WebView component. Generate the URI with the library you are using. It will look similar to:

https://your-id-server.com/openid/auth?redirect_uri={YOUR REDIRECT URI}&client_id={YOUR CLIENT ID}&response_type=id_token&scope=openid%20profile%20email

On successful sign-in the user is redirected to the selected URI with parameters in the fragment (by default), as described here. You can read the ID token, Access token and other information from the received parameters. On failed sign-in the same URI is called with error parameters as described here. The library you use should be able to parse the parameters.

The received ID token must be validated as described here to prevent a fake or an expired ID token being accepted. The library you use should handle validation.

You can parse the claims from the ID token, or from the UserInfo endpoint to get identity information about the user:

• sub: The user ID value; an unique identifier for the user

• email: Email address (if email scope was used)

• email_verified: boolean, is email address verified (if email scope was used)

• And many others. See also scope requirements.

Integrating the sign-in-name and password fields into the app

See https://trivore.atlassian.net/wiki/spaces/TISpubdoc/pages/20515382 .