Provide extra context during client credentials token exchange

[buck]

I am building a multi-tenant application where we have a concept of an organization that has users. Our application is modeled such that a user can belong to many organizations, but the user can only be logged into one of them at a time. I am attempting to come up with a solution in Auth0 for putting the ID of the organization the user is currently using within the JWT access token.

In terms of when the user is logging into the app, our idea here is to have one Auth0 Application per organization where the Application has metadata about which organization it represents.

The problem comes as I am trying to allow our services to communicate with each other and also have the access tokens scoped down to a single organization. Originally, I had thought I would put metadata in these Auth0 Applications which indicate they have permission to access any organization and then use a scope when getting a token to indicate organization I want right now. For example, I would request a token with scope org:xyz and have an Auth0 Hook which could cross-check this scope with the metadata to know whether to allow it.

The problem is that there’s no way to specify a scope in the /oauth/token route for the client_credentials token. I cannot find any other way to indicate to the hook which org I am trying to access.

So my questions are twofold:

1. Is there some way to provide this contextual information to Auth0 so that in my hook I know which organization ID to put in the token?
2. If not, any other architectural suggestions for dealing with the setup described above?

[mathiasconradt]

You should use Rules instead of Hooks. Rules are a way to intercept the authentication flow, while Hooks happen at other times (i.e. user signup). See Auth0 Rules

In such rules, you can modify ID and access tokens, you can also set the scope in a rule.
See Rule Examples

The context object would be the right place to check for a parameter to distinguish between the different organizations somehow. How does the application distinguish? Different subdomains, url path, or a selector/drop down list where the user selects from?

Depending on the criteria to distinguish between organisations, you might use this approach mentioned here config for hosted login page as one option.

Especially for Client Credentials Token Exchange, this docs page might also be of interest: Client Credentials Exchange