The JSON Web tokens (JWT) used by OIDC and OAuth applications contain pieces of information about the user known as claims. A JSON Claim is information that an identity provider states about a user inside the token they issue for that user. These claims are used to
In an OIDC response, claims data is typically contained in the ID Token issued by the identity provider in the form of a JWT. Identity mappings contain JSON Claims that are used to provide token information.
JSON web token claims are pieces of information asserted about a Subject (user). For example, an ID token, which is always a JWT, can contain a claim called name that asserts that the name of the user undergoing authentication is "Sally Doe". In a JWT, a claim appears as a name/value pair where the name is always a string and the value can be any JSON value.
For example, the following JSON object contains three claims (sub, name, admin):
{
"sub": "1234567890",
"name": "Sally Doe",
"admin": true
}The JWT specification defines seven reserved claims that are not required, but are recommended to allow interoperability with third-party applications. They include the following basic claims:
JSON Claim | Description |
|---|---|
sub (subject) | Subject of the JWT (user’s identity) |
iss (issuer) | Issuer of the JWT |
aud (audience) | Recipient of the JWT |
iat (issue time) | Time at which the JWT was issued; can be used to determine age of the JWT |
exp (expiration time) | Time after which the JWT expires |
nbf (not before time) | Time before which the JWT must not be accepted for processing |
jti (JWT ID) | Unique identifier; can be used to prevent the JWT from being replayed (allows a token to be used only once) |
For more information, see a list of OIDC standard user claims. See also a full list of JSON claims.
You can define your own custom claims which you control and you can add them to a token by configuring them in the identity mapping that you create for an OIDC integration.
When you configure your cloud to trust GitHub's OIDC provider, you must add conditions that filter incoming requests, so that untrusted repositories or workflows will not be able to request access tokens for your cloud resources. We strongly encourage people to set at least one claim in the identity mapping. If you don't add claims anyone that knows the service account to target can get access.
Before granting an access token, your cloud provider checks that the subject and other claims used to set conditions in its trust settings match those in the request's JSON Web Token (JWT). As a result, you must ensure you correctly define the subject and other conditions in your cloud provider. See also Security Hardening.
The OIDC trust configuration steps and the syntax to set conditions for cloud roles (using Subject and other claims) will vary depending on which cloud provider you're using. For some examples, see Example subject claims.
Multiple Values
From Artifactory version 7.94.1, multiple values are supported for JSON Claims. Identity mappings use JSON Claims to define the scope of generated access tokens. You can now define the scope of an access token for multiple values, for example for multiple repositories and environments.
Example
Following is an example of a JSON Claim definition for multiple repositories.
{
"repository":["jfrog/jfrog-cli", "jfrog/artifactory-client-java", "jfrog/setup-jfrog-cli"]
}Wildcard Values
Wildcard values are supported from Artifactory version 7.94.1 for JSON Claims. You can now define the scope of an access token using wildcard values, and can use both explicit and implied patterns.
Examples
Following are two examples of a JSON Claim definition for repositories using a wildcard.
{
"repository": "jfrog/*"
}{
"repository": "jfrog/jfrog-cli/**"
}