[AlphaConfig] Some claims in OIDC token not accessible by ClaimSource

Author: joraffCreated Jan 5, 2023Updated Aug 24, 2026
Labelsenhancementhelp wantedgood first issueneeds tests

When successfully getting a token from an OIDC provider that includes claims like upn, given_name, and family_name, those claims are not being read by ClaimSource data type in alphaConfig, such as for use in injectRequestHeaders.

Expected Behavior

The following code should create a X-Provider-User user with the upn value from the ID token:

yaml
injectRequestHeaders:
  - name: X-Provider-User
    values:
      - claim: upn

Repeat with claims family_name, given_name, and email. All claim values are being provided by the IdP, but only the email claim results in a header being set.

Current Behavior

The HTTP header X-Provider-{claim} is blank, other than {claim}=email.

Possible Solution

Observations: if I intentionally leave off a config value, such as not setting audienceClaims: ["aud"], I can see that the claim values are present:

[azure.go:291] unable to verify ID token, fallback to access token: audience claims [] do not exist in claims: map[aio:AUQAu/8TAAAAwY8+3Lyb0XqRWZIwgzZLCRbPFeS58EnVnBs6yu84l5fPT2dA2kLU9WssrFopPZCZds6luxuHfJJQmbBVPhoBfA== aud:3ec49072-7365-4065-8494-df5d8eb67a58 email:[email protected] exp:1.672879765e+09 family_name:Rafferty given_name:Joseph iat:1.672875865e+09 iss:https://login.microsoftonline.com/68f381e3-46da-47b9-ba57-6f322b8f0da1/v2.0 name:Rafferty, Joseph R nbf:1.672875865e+09 oid:fba7fc62-a397-4d14-b310-cd760f937278 preferred_username:[email protected] rh:0.AUUA44HzaNpGuUe6V28yK48NoXKQxD5lc2VAhJTfXY62elhFAOw. sub:3v5IpE6N3MdLwjo7WjzaTKZLxXz49e7bn4LO5zO6Vwg tid:68f381e3-46da-47b9-ba57-6f322b8f0da1 upn:[email protected] uti:IlvulaJSTUqJQ9UYKX4hAw ver:2.0]

Successful token gives this log output:

[AuthSuccess] Authenticated via OAuth2: Session{email:[email protected] user:3v5IpE6N3MdLwjo7WjzaTKZLxXz49e7bn4LO5zO6Vwg PreferredUsername:[email protected] token:true id_token:true created:2023-01-04 18:34:10.211261 -0600 CST m=+24.669597876 expires:2023-01-04 19:40:42.678696 -0600 CST m=+4017.137035709}

Steps to Reproduce (for bugs)

  1. Configure again Azure AD
  2. Configure AlphaOptions with a claim HTTP header injection. v
  3. Observe the log output the for claims
  4. Observe the HTTP headers sent to the upstream
  5. Observe the JWT set in the cookie header.

Context

Your Environment

alphaConfig:

yaml
upstreamConfig:
  upstreams:
    - id: echo
      path: /
      uri: http://127.0.0.1:8081
injectRequestHeaders:
  - name: X-Provider-User
    values:
      - claim: upn
  - name: X-Ready-Email
    values:
      - claim: email
 
providers:
  - id: azure
    name: Azure AD
    provider: "oidc"
    clientId: "{clientId}"
    clientSecret: "{secret}"
    azureConfig:
      tenant: "{tenant}"
    oidcConfig:
      issuerUrl: "https://sts.windows.net/{tenant}/"
      audienceClaims:
        - aud
      emailClaim: email
      userIDClaim: upn
    scope: "openid email profile"
server:
  bindAddress: 127.0.0.1:8080

The log output

  • Version used: v7.4.0

Source: oauth2-proxy/oauth2-proxy