# Use IdP Standard Claims

**URL:** https://discuss.pomerium.com/t/use-idp-standard-claims/310
**Category:** Support
**Created:** [September 21, 2023, 3:46pm UTC](https://discuss.pomerium.com/t/use-idp-standard-claims/310 "2023-09-21T15:46:44Z")
**Posts on this page:** 9
**Page:** 1

<div class="post-metadata">

### Author: ![Dennis](https://avatars.discourse-cdn.com/v4/letter/d/e56c9b/32.png) [@Dennis](https://discuss.pomerium.com/u/Dennis)
#### Post date: [September 21, 2023, 3:46pm UTC](https://discuss.pomerium.com/t/use-idp-standard-claims/310/1 "2023-09-21T15:46:44Z")

</div>

## What happened?

In our existing application, we forward the access token to upstream app and get standard claims data from it. We want to avoid passing the IdP access token to upstream application and use JWT assertion token instead, but we need to pass some standard claim. For now we just know we can pass custom claim using [jwt claim headers](https://www.pomerium.com/docs/reference/jwt-claim-headers#customize-header-names)

Access Token

```auto
{
  "custom_user_id": "xxxx-xxxx-xxxx-xxxx",
  "ext_role": "",
  "iss": "https://yyy.auth0.com/",
  "sub": "auth0|xxxx123",
  "aud": [
    "https://xxx/",
    "https://yyy.auth0.com/userinfo"
  ],
  "iat": 1695266371,
  "exp": 1695352771,
  "azp": "SOME_CLIENT_ID",
  "scope": "openid profile email offline_access",
  "permissions": [ 
    "read:transaction",
    "create:transaction"]
}

```

On the above example I can pass `custom_user_id` but cannot pass `permissions` as it is a “standard claim”.

## What did you expect to happen?

I can pass the permissions as header, instead of the whole access token. Or, the permission is reflected in JWT Assertion Token

## More Context

We use auth0 as the IdP. We do this because the existing app use permissions to do application-level authorization , but we do not want to pass the access token for security reason but we want to do minimal changes in the upstream apps.  
Or are we approaching this problem the wrong way? Any suggestion?

---

<div class="post-metadata">

### Author: ![calebdoxsey](https://avatars.discourse-cdn.com/v4/letter/c/7bcc69/32.png) [@calebdoxsey](https://discuss.pomerium.com/u/calebdoxsey)
#### Post date: [September 21, 2023, 5:00pm UTC](https://discuss.pomerium.com/t/use-idp-standard-claims/310/2 "2023-09-21T17:00:06Z")

</div>

The `jwt_claims_headers` option should support standard claims like `permissions`. The only unsupported claims are the ones we always define: (in other words they are supported, but don’t come directly from the IdP claims in the same way)

- `iss`
- `aud`
- `jti`
- `exp`
- `iat`
- `sub`
- `user`
- `email`
- `groups`
- `sid`
- `name`

There may be a bug here or something else going on. I will investigate.

---

<div class="post-metadata">

### Author: ![calebdoxsey](https://avatars.discourse-cdn.com/v4/letter/c/7bcc69/32.png) [@calebdoxsey](https://discuss.pomerium.com/u/calebdoxsey)
#### Post date: [September 21, 2023, 5:59pm UTC](https://discuss.pomerium.com/t/use-idp-standard-claims/310/3 "2023-09-21T17:59:47Z")

</div>

`permissions` doesn’t appear to be a claim added by Auth0. It is a custom claim which requires a post-login script in Auth0. We have documentation for adding groups claims: [Auth0 | Pomerium](https://www.pomerium.com/docs/identity-providers/auth0#groups). I attempted to write a script in Auth0 to add the permissions as a claim in a similar manner, but I wasn’t able to figure it out.

They have a post about it here: [How to add Roles and Permissions to the ID Token using Actions? - Auth0 Community](https://community.auth0.com/t/how-to-add-roles-and-permissions-to-the-id-token-using-actions/84506) but it doesn’t include a concrete example of how to use the management API to query the permissions and add them as a claim.

---

<div class="post-metadata">

### Author: ![Dennis](https://avatars.discourse-cdn.com/v4/letter/d/e56c9b/32.png) [@Dennis](https://discuss.pomerium.com/u/Dennis)
#### Post date: [September 22, 2023, 4:16am UTC](https://discuss.pomerium.com/t/use-idp-standard-claims/310/4 "2023-09-22T04:16:29Z")

</div>

Yes, we are trying to pass the `permissions` to the claim header / jwt access token at the moment, but have not found the way to do it. We are not really sure whether the permissions are custom or standard claims if it is added by the Management API.

Can we pass the value of the ‘unsupported’ claims that come directly from IdP claims in different way that you mentioned? This use case also talks about forwarding any value that exists in id / access token but not in jwt assertion header

---

<div class="post-metadata">

### Author: ![Dennis](https://avatars.discourse-cdn.com/v4/letter/d/e56c9b/32.png) [@Dennis](https://discuss.pomerium.com/u/Dennis)
#### Post date: [September 26, 2023, 10:20am UTC](https://discuss.pomerium.com/t/use-idp-standard-claims/310/5 "2023-09-26T10:20:38Z")

</div>

Also , i tried a workaround, which is not really preferred, if the above issue can actually be addressed, by making a script in auth0 actions to make http call to the management API and get the user permissions. Then I set these permissions as custom claim in access token and pass them as req headers in pomerium.

```auto
api.accessToken.setCustomClaim("abc", ["hehe","haha"]);

```

But it turns out the pomerium can’t pass it if it is only set in access token so i need to add

```auto
api.idToken.setCustomClaim("abc", ["hehe","haha"]);

```

Why is that so?

Config

```auto
jwt-claim-headers:
   X-Custom-ABC: abc

```

Access Token

```auto
{
  ....
  "abc": [
    "hehe",
    "haha"
  ],
 ....
  "permissions": [
    "read:api:permission"
  ]
}

```

Req Header

```auto
  "X-Custom-Abc": "hehe,haha", 

```

---

<div class="post-metadata">

### Author: ![calebdoxsey](https://avatars.discourse-cdn.com/v4/letter/c/7bcc69/32.png) [@calebdoxsey](https://discuss.pomerium.com/u/calebdoxsey)
#### Post date: [September 26, 2023, 9:24pm UTC](https://discuss.pomerium.com/t/use-idp-standard-claims/310/6 "2023-09-26T21:24:34Z")

</div>

Hi Dennis,

That’s surprising that it would only work for the id token. I believe it should work for both. I’ll file an issue and investigate.

---

<div class="post-metadata">

### Author: ![calebdoxsey](https://avatars.discourse-cdn.com/v4/letter/c/7bcc69/32.png) [@calebdoxsey](https://discuss.pomerium.com/u/calebdoxsey)
#### Post date: [September 26, 2023, 9:26pm UTC](https://discuss.pomerium.com/t/use-idp-standard-claims/310/7 "2023-09-26T21:26:37Z")

</div>

> <https://github.com/pomerium/pomerium/issues/4588>
>
> \## What happened?
> It appears that setting a custom claim on the access token in… auth0 does not work when passed through.
> 
> A custom script in auth0:
> 
> \`\`\`
> api.accessToken.setCustomClaim("abc", \["hehe","haha"\]);
> \`\`\`
> 
> With this config
> 
> \`\`\`yaml
> jwt-claim-headers:
> X-Custom-ABC: abc
> \`\`\`
> 
> The claim is not appearing in the JWT assertion.
> 
> \## What did you expect to happen?
> 
> For the claim to appear in the JWT assertion.

---

<div class="post-metadata">

### Author: ![calebdoxsey](https://avatars.discourse-cdn.com/v4/letter/c/7bcc69/32.png) [@calebdoxsey](https://discuss.pomerium.com/u/calebdoxsey)
#### Post date: [September 28, 2023, 3:10pm UTC](https://discuss.pomerium.com/t/use-idp-standard-claims/310/8 "2023-09-28T15:10:48Z")

</div>

Hi Dennis,

Looking into this further, I’m not sure using access token claims will work. I believe Auth0 issues “opaque” access tokens by default. These are in a format that can only be used with the user info endpoint. To get JWT access tokens additional audiences need to be passed to the Auth0 API.

Since using the id token does seem to work, is it ok to just use that instead?

---

<div class="post-metadata">

### Author: ![Dennis](https://avatars.discourse-cdn.com/v4/letter/d/e56c9b/32.png) [@Dennis](https://discuss.pomerium.com/u/Dennis)
#### Post date: [September 29, 2023, 8:28am UTC](https://discuss.pomerium.com/t/use-idp-standard-claims/310/9 "2023-09-29T08:28:22Z")

</div>

Hi Caleb,

I don’t think it is not a good solution in our use case. We find that management API in auth0 also has a relatively ‘low’ rate limit , I don’t think it is supposed to be for high-intensity flow such as login.

Also,CMIIW, but I don’t think we use opaque access token since we can decrypt the token directly
