# Enrich Access and ID Token

Client SDK
Sub-journey
> Allows adding custom data to the OIDC tokens


## Description

This step is used to add information that can be utilized by the relying party as part of the returned access or ID token. These pieces of information can be added as fully customizable key-value pairs, allowing you to gather relevant data about the authentication process.

You can control where enriched claims appear in the access token:

- Under a dedicated `custom_claims` object (default), which reduces the risk of collisions with standard JWT claims and provides a stable structure for token consumers.
- At the top level of the access token payload, which is useful when migrating from another identity provider (for example, Okta or Auth0) or when downstream services expect claims like `loyalty_tier` or `risk_level` directly at the token root.


Root placement currently applies only to the access token. Enriched claims in the ID token are always nested under `custom_claims`, regardless of the Placement setting.

## Configuration

| Field | Description |
|  --- | --- |
| **Token type** | The token type to be enriched with custom claims (Access token, ID token, or both). |
| **Token enrichment values** | Custom key values that will be used as custom claims in the OIDC access and ID tokens. |
| **Placement** | Where to insert enriched claims in the access token payload:- **custom_claims** (default): insert claims under the `custom_claims` object.- **root**: insert claims at the top level of the access token payload.This setting applies only to the access token. Enriched claims in the ID token are always nested under `custom_claims`, regardless of the Placement setting. |


Journey event data
This step can be configured to record step input and output data, or a custom payload, which is then surfaced in journey events in Journey Analytics for diagnostic purposes. For details, see [Additional data reporting](/guides/orchestration/getting-started/event_reporting).

## Example

Consider a scenario where a retail company wants downstream services to know the user's loyalty tier and risk level calculated during the journey. By including these values as custom claims in the OIDC access and ID tokens, you can securely return additional information to the client application upon journey completion, providing context for authorization and business logic (for example, show premium perks for `loyalty_tier: "gold"` or require step-up actions when `risk_level` is high).

The following example uses `placement: custom_claims` and includes `loyalty_tier: "gold"` and `risk_level: "low"`:

```json
{
  "sub": "123",
  "iss": "https://userid.security",
  "custom_claims": {
    "loyalty_tier": "gold",
    "risk_level": "low"
  }
}
```

- With `placement: root`, claims are added at the root of the access token payload:


```json
{
  "sub": "123",
  "iss": "https://userid.security",
  "loyalty_tier": "gold",
  "risk_level": "low"
}
```

Note
Root placement applies only to the access token. The ID token always nests enriched claims under `custom_claims`, regardless of the Placement setting. When using `placement: root`, you must never overwrite [reserved JWT claims](/openapi/id_token_reference#default-claims) such as `iss`, `sub`, `aud`, `iat`, and `exp`.