Sharing Claims

There are 3 ways in which claims can be shared:

1. Automatically in identity or access tokens issued (with user consent if required).

2. Automatically by an account client via the Management API (with user consent if required).

3. Automatically by an admin client via the Management API (no user consent).

Injected in identity/access tokens

Account claims can be automatically injected in any identity or access tokens issued by using control configuration. Controls are things a user must pass in order to gain access, for example consenting to Terms & Conditions (T&C's) or granting an application certain API access (scopes).

Claims are injected into tokens using the value of the attribute as the claim key:

{
    // other ID or access token claims
    "<attribute_value>": "<claim_value>"
}

Please note that claims are correctly injected according to their subtype:

• string* are injected as strings.

• number* are injected as numbers.

• boolean* are injected as booleans.

• json* are injected as JSON objects.

Please note that only attributes with a status ENABLED or PENDING will be injected into tokens, and if the account does not have any enabled or pending claims for an attribute no claim will be populated in the token.

If the attribute requires validation for enablement then an additional verified claim will be injected:

{
    // other ID or access token claims
    "<attribute_value>": "<claim_value>",
    // if attribute requires validation
    "<attribute_value>_verified": true // IF STATUS IS ENABLED
    "<attribute_value>_verified": false // IF STATUS IS PENDING
}

Please note that if an account has multiple claims for the same attribute they'll all be injected as an array:

{
    // other ID or access token claims
    "<attribute_value>": [ "<claim_value1>", "<claim_value2>" ]
    // if attribute requires validation
    "<attribute_value>_verified": [ true, false ] // INDEX MAPPED TO VALUES
}

In the Admin UI admins can configure the attributes included by going to Controls, select the desired control, and go to the Attributes section.

In the example above we have configured a profile scope that if obtained by an application will result in the nickname, middle name, name, family name and given name to be injected into the identity token. In this case the the profile scope requires consent so in case it concerns an external application than the user must explicitly consent the application can obtain the profile scope.

External account access

An account can grant an external application access to their account. This involves granting the default Account Access scope (https://api.quasr.io/scopes/account) which generally requires consent, so if the user wants to grant this scope to an external application, they have to explicitly consent. Once the application has the scope it can access and manage the user's account on their behalf, including seeing all of the users' claims regardless of score.

It's not recommend to allow the account access scope to be granted to an external application as it grants too much control over the user's account. We've recently added fine-grained scopes which are recommended for granted access to a user's account on a more granular level. You can grant various read and write access.

External admin access

An admin can grant an external application access to a tenant. This involves granting the default Admin Access scope (https://api.quasr.io/scopes/admin) which generally requires consent, so in case the admin wants to grant this scope to an external application they first have to explicitly consent. Once the application has the scope it can access and manage the tenant - including seeing all of the users' claims regardless of score and possibly not with their explicit consent (or the sharing needs to be covered by an earlier general consent).

It's not recommend to allow the admin access scope to be granted to an external application as it will grant too much control over the tenant and access to all of the user's personal data. We've recently added new fine-grained scopes which are recommended for granted access to a tenant on a more granular level. You can now grant various read and write access.