Get User Identity and Trust
Every time your users login using BindID, you receive user metadata containing their user identity and trust profile. BindID maintains a trust profile for each user and their devices—such as when the user was first or last seen by you or by any provider integrated with BindID. The user metadata can be obtained from the ID token or UserInfo using backend OIDC APIs, as described below.
Get ID and Access Tokens
For each successful authentication, the BindID SDK returns an authorization code, which you can exchange for ID and access tokens. The ID token contains the user metadata, as well as trust indicators for the device and authenticator used in the authentication session. The access token can be used in various other API requests, such as to report and retrieve data for the authenticated user.
To get an ID and access token, send a HTTP POST request to the OIDC
/token endpoint. The request body should include the authorization code returned by the SDK, the redirect URI you passed in the authentication request, and your client credentials. See the Token API reference.
/token response includes the ID token in the
id_token field, which you can decode to obtain the user metadata.
Note: The client should resolve the authorization code and exchange tokens at the backend; backend systems must not assume tokens received from the client are valid without validating them—including the intended audience and nonce (see Validate ID Tokens).
Get User Information
You can also obtain the user metadata from the OIDC
/userinfo endpoint, for example, if required for your OIDC implementation. Send an HTTP GET or POST request to the OIDC
/userinfo endpoint. The Authorization header should include the access token returned in the
/token response in the
access_token field. See the UserInfo API reference.
/userinfo response includes the user metadata directly in the body.
Handle User Token
The user metadata may correspond to a user that's already known to BindID or a new user:
- If the user is unknown to BindID, the ID token (and UserInfo response) will not include the
bindid_aliasclaim. The application should respond by taking the user through a registration process where the application establishes user identity (see Send Session Feedback). Afterwards, the application should set a BindID alias for the user so that subsequent logins will be associated with it.
- If the user is known to BindID, the ID token (and UserInfo Response) will include the
bindid_aliasclaim. Your application should look up this value within its user-store to identify the application user to which this alias is registered, and use that user for the rest of the session.