Read Okta's ID token claim for adaptive content

[nick-short-oe]

We have Okta set up for authenticated access and want to apply Adaptive Content based on custom user profile attributes (e.g., teams or department).

Okta correctly passes these custom attributes inside the ID Token, but our testing shows that GitBook’s visitor.claims engine is currently only parsing the Access Token. As noted in Okta's documentation, relying on the Access Token for user identity is not best practice, as it is intended to be an opaque authorization token.

Because we use Okta's standard Org Authorization Server, Okta strictly strips custom claims from the Access Token and places them exclusively in the ID Token (or makes them available via the standard /userinfo endpoint). We are not in a position to purchase Okta's API Access Management module just to force custom claims into an Access Token, especially when the standard OIDC ID Token already contains the data.

For now, our only workaround is to use the sub claim from the Access Token to manually list individual user email addresses in GitBook's access conditions. This is not feasible or scalable for large audiences.

Request:
Could GitBook's OIDC implementation be updated to evaluate visitor.claims from the ID Token payload?

[aikoii]

Hey @nick-short-oe 👋 Thanks for the detailed context! You’re correct that GitBook currently evaluates custom OIDC claims for adaptive content from the Access Token rather than the ID Token.

I don't expect it to change in the near future, but we'll keep you posted if anything does.