I see the issue with your Oathkeeper header mutator configuration. The problem is in how you're trying to access the email claim from the token. Based on your introspection response, the email is stored in

ext.x-user-email

, but in your header mutator configuration, you're trying to access it with

.Extra.x-user-email

or possibly

.Extra.identity.traits.email

(based on the error message). In Oathkeeper, when using the OAuth2 introspection authenticator, the

ext

field from the introspection response is mapped to the

.Extra

field in the authentication session. However, you need to use the correct path to access the nested fields. Here's how you should modify your header mutator configuration:

yaml mutators:   header:     enabled: true     config:       headers:         X-User: "{{ print .Subject }}"         X-User-Email: "{{ print .Extra.x-user-email }}"

The error message suggests you might be trying to access

.Extra.identity.traits.email

, which would be the path for Kratos identity data, not for the OAuth2 introspection data structure. Also note that your introspection response shows the email value as

"<mailto:email@gmail.com|email@gmail.com>"

, which contains special formatting. You might need to clean this up depending on your requirements. For more information about the header mutator and how to access session variables, you can refer to the [Oathkeeper header mutator documentation](https://www.ory.sh/docs/oathkeeper/pipeline/mutator#header). If you're still having issues, you might want to try using the hydrator mutator first to debug the session data structure, which can help you understand exactly what fields are available in the

.Extra

object.

The hydrator mutator in Ory Oathkeeper allows you to fetch additional data from external APIs and use it in subsequent mutators. This is particularly useful for enriching the authentication session with extra information. Here's how to use the hydrator mutator: ## Configuration You need to configure the hydrator mutator both globally and in your access rules: ### Global Configuration

yaml mutators:   hydrator:     enabled: true     config:       api:         url: <http://my-backend-api>         auth:           basic:             username: someUserName             password: somePassword         retry:           give_up_after: 2s           max_delay: 100ms       cache:         ttl: 60s

### Access Rule Configuration

yaml mutators:   - handler: hydrator     config:       api:         url: <http://my-backend-api>

## How It Works 1. The hydrator makes a POST request to the specified API URL 2. It sends the current authentication session as a JSON payload 3. Your API should process this data and return a modified version 4. The returned data replaces the original authentication session ## Example Payload The hydrator sends a JSON payload like this:

json {   "subject": "anonymous",   "extra": {     "foo": "bar"   },   "header": {     "foo": ["bar1", "bar2"]   },   "match_context": {     "regexp_capture_groups": ["http", "foo"],     "url": "<http://domain.com/foo>"   } }

Your API should return a similar structure with modified

extra

or

header

fields. ## Complete Access Rule Example Here's a complete example showing how to use the hydrator with another mutator:

json {   "id": "some-id",   "upstream": {     "url": "<http://my-backend-service>"   },   "match": {     "url": "<http://my-app/api/<.*>>",     "methods": ["GET"]   },   "authenticators": [     {       "handler": "anonymous"     }   ],   "authorizer": {     "handler": "allow"   },   "mutators": [     {       "handler": "hydrator",       "config": {         "api": {           "url": "<http://my-backend-api>"         }       }     },     {       "handler": "cookie",       "config": {         "cookies": {           "some-arbitrary-data": "{{ print .Extra.cookie }}"         }       }     }   ] }

In this example, the hydrator fetches data from your API, and then the cookie mutator uses that data to set a cookie. For more details, see the [Oathkeeper hydrator mutator documentation](https://www.ory.sh/docs/oathkeeper/pipeline/mutator#hydrator).

Based on the knowledge sources, I can provide you with information about the OAuth2 token introspection response structure in Ory Hydra. When you introspect an OAuth2 token using Ory Hydra's introspection endpoint, the response follows the structure defined in [IETF RFC 7662](https://tools.ietf.org/html/rfc7662) with some Ory-specific additions. Here's the standard structure:

json {   "active": true,   "aud": ["audience1", "audience2"],   "client_id": "client-identifier",   "exp": 1744740260,   "ext": {     "client_name": "client",     "custom_field": "custom_value"   },   "iat": 1744725860,   "iss": "<https://issuer-url/>",   "nbf": 1744725860,   "obfuscated_subject": "pairwise-subject-identifier",   "scope": "scope1 scope2",   "sub": "user-identifier",   "token_type": "Bearer",   "token_use": "access_token",   "username": "user-friendly-identifier" }

Key fields in the introspection response: - `active`: Boolean indicating if the token is currently active - `aud`: List of the token's intended audiences - `client_id`: Identifier for the OAuth 2.0 client that requested the token - `exp`: Expiration timestamp (seconds since Jan 1, 1970 UTC) - `ext`: Object containing arbitrary data set by the session - `iat`: Issued at timestamp - `iss`: String representing the token issuer - `nbf`: Not before timestamp - `obfuscated_subject`: The

sub

value of the ID Token when using pairwise subject identifiers - `scope`: Space-separated list of scopes associated with the token - `sub`: Subject of the token (usually the resource owner's identifier) - `token_type`: Typically "Bearer" - `token_use`: For example "access_token" or "refresh_token" - `username`: Human-readable identifier for the resource owner The

ext

field is particularly important as it contains any custom data that was added to the token, which is what you were trying to access in your previous questions. [Hydra API Reference](https://www.ory.sh/docs/hydra/reference/api) and [Ory API Reference](https://www.ory.sh/docs/reference/api) both document this structure in their introspectOAuth2Token method responses.