This article is the story of how this issue bugged me so much that I took it on myself to work with the IETF standards community to try fixing it, culminating in the publication of a new standard document describing how to encode and validate an OAuth 2.0 AT in JWT format.
Read more…
Brought to you by @Vittorio
Folks! Let us know if you have any comments or thoughts! 
This topic was automatically closed after 24 days. New replies are no longer allowed.
Is this standard implemented in Auth0? I can’t find a way to request Access Tokens in the RFC 9068 format.
Hi @david.poirier,
Welcome to the Auth0 Community 
Currently, Auth0 doesn’t support RFC 9068 for its access tokens.
I was just now trying to make my access tokens rfc9068 compliant by adding custom claims in a custom action, seems simple enough but the client_id key is silently ignored?
Hello @dave.higgins,
Welcome to the Auth0 Community!
I’m afraid you can’t use client_id as a custom claim due to some naming restrictions.
@andrea.chiarelli thanks, I’ve seen you return the client id in the authorized parties claim “azp”, do you know if this part of any standard RFC across many authorization providers such as Auth0?
We’re trying to figure out a standard to conform to in accepting access tokens to our resource servers from dynamically registered authorization servers, so of course we need issuer, subject and clientid claims in there to figure out how to contact the corresponding authorization server.
I settled so far on RFC 9068, but we can allow the client id claim to be configurable by the user although this would be a bit of a homebrew, but if auth0 jwt access tokens are conforming to some other RFC we could avoid that.
I think that the azp claim was borrowed from the OIDC specification.
This post briefly explains why it is in our access tokens.
As far as I know, there are no other RFCs that define access tokens in JWT format.
