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, an ID and access token can be retrieved from BindID. 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.
For example:
The /token
response includes the ID token in the id_token
field, which you can decode to obtain the user metadata.
For example:
Note: Unless a PKCE token exchange flow is used, 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.
For example:
The /userinfo
response includes the user metadata directly in the body.
For example:
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_alias
claim. 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_alias
claim. 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.