Is there an equivalent to request.session for storing additional data along with an access token?

[decibyte]

I'm all new to both OAuth and DOT, so please bear with me, if this is a dumb question.

We currently have 2 ways of authenticating: Regular session based auth and JWT.

With both of them, we store some data (e.g. the ID of the organization you're logged in to) in either the session or the returned JWT payload, depending on the authentication method.

Is there a similar way to store additional data along with an OAuth access token?

[dopry]

You might look at the standard claims,

https://www.cerberauth.com/blog/openid-connect-standard-claims/
https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims

It's not uncommon to see an org prefix in the sub claim, especially when authenticating with a social login like google or facebook. How you store it is kind of up to you and whether you're using just basic OAuth2 or OIDC, what flow you're using, how you're using the tokens, and you approach to authorization.

If you could expand on the use case I may be able to provide additional feedback. When you say org that you are logged into, are we talking unique identities per org, or a single identity with access to multiple orgs... In the former approach sub prefixing would probably be a good approach... in the latter you probably don't need to store the 'org' in the token, but maybe you could get away with just a session variable for the current org.

alternatively, you could go so far as to embed explicit permissions (list of orgs/groups, roles/perms within each) into the claims of the token to control access. but you end up with really big tokens and latency(token lifetime) for permissions updates vs and authorization server or embedded authorization in the RP that just needs the issuer and sub.