Recommendations for use of ID Service infrastructure in your application stack
User management
Your user account profiles will be stored in the ID service. The recommended way to register these accounts is through a OpenID Connect based web form which the ID service provides. Alternatively, your backend can create user accounts through the Management API.
In most cases the end user accounts have been stored in a separate namespace in the ID service. This is optional, however. The organisation of end users and other users (administrators, client profile owners) is a question of taste.
Frontend
User registration
The user can be directed to the ID service’s sign-in page, where they can register a new account. The registration form can optionally perform email address and mobile number verifications.
Alternatively your backend can register accounts based on a registration process you implement in your app.
User sign-in
Users can log in with their credentials, which are a sign-in name (username or verified email or verified phone number) and a password.
You can implement the sign-in through various OAuth2 / OpenID Connect authentication flows:
-
Authorization Code, Implicit, or Hybrid flows: Your app opens the sign-in view, the user authenticates, and is redirected back to your application. Due to a (so far unexplained) conflict between the UI framework used in the sign-in service, and Apple Safari implementation, the redirect may not work on iOS devices correctly when using custom URL schemes.
-
Password Grant flow: Your app asks the user to enter their sign-in credentials in a screen of your own design, and you pass those credentials to the ID service directly.
Some OpenID Connect features do not work in this flow, specifically support for the claims-parameter. Claims can still be requested using specific scope value which grant them.
Because using Password Grant Flow results in your app gaining access to the user credentials, this is a weaker security solution, and an admin on the ID service must enable Password Grant for your client before it can be used.
After sign-in your app has received an Access Token, a Refresh Token, and an ID Token.
-
Access Token: Used to access API endpoints on the ID service.
-
Refresh Token: Used to retrieve a new Access Token when it expires.
-
ID Token: Contains identifying details (“claims”) about the authenticated user. The token is signed by the ID Service, therefore it can be used as a proof of user account identity. One use case is to provide this token to your backend server, which can then verify the token and the associated user identity before executing actions your app requests.
ID Service APIs
Your app may use the tokens it received to use some of the APIs the ID Service provides. This spares your backend from performing some simple actions, such as user profile updates. The Access Token is used as a Bearer token in most of these calls.
Backend - Your server
Your backend service can use the Management API with credentials that have more permissions that normal users. In addition to the Access Tokens, the API supports simpler Basic Auth based Management API Client credentials. These credentials are generated by adding a new API Client profile to the ID service, configuring what permissions it is given, and retrieving the credentials: client ID and secret. The account that created the client profile is marked as its owner, and the client is ultimately limited by the owner’s permissions and access.
Connection between your frontend and your backend
Your frontend must communicate the identity of the authenticated user to your backend. How you achieve this securely is up to you.
You can use the ID Token as a tool here. It provides a proof of
-
used ID Service,
-
user identity, and
-
client identity (in Authorization Code flow).
The standard claims iss (issuer of the token = the ID service), sub
(subject of token = the user ID) and aud (audience of the token = the
client ID) provide these details, and the signature validation your
backend can do using the public keys from the expected ID service can
help you implement your solution.
See ID Token in OpenID Connect Core.
User registration and management
User registration can be performed by your backend server if you don’t want to or can’t use the web based OpenID Connect sign-in/registration form. Your API client profile must have the required permissions for administering users in the end user namespace.