@asahaf
This is a lot to tackle in one post, but we’ll do what we can 
.
It sounds like you will probably have a common database where all of your users authenticate since one user can access multiple organizations. Then you will have to distinguish different permissions in a user’s app_metadata for each different organization so they can have different roles/permissions for each application.
If you set it up this way, I would recommend authorizing a user for a particular organization. One way that you can accomplish what you are looking for would be to have a different API for each organization.
For example: https://your-domain.com/org1/api, https://your-domain.com/org2/api, etc.
The advantage of this, is that you can get a new access_token for each org1. Therefore, in your application, when you send a request to /authorize, you can add audience to your request. This audience can then be found in your rule at context.request.query.audience. You can use that audience then to pull only the permissions you are allowing from the app_metadata for this person, for that specific org and add them as a custom claim to the access_token or use them to set context.accessToken.scope to the right scopes for this org.
Assuming you won’t have one client calling out to many different orgs in a single instance, this should be a fairly smooth way to handle this interaction. This can get a little tricky if you are using refresh tokens instead of redirecting to authorize for a new access_token because you don’t have access to the audience in the rule, but in the case of a refresh token, it should be specific to the audience already and should only give you back the same scopes you had before by default. Just keep that in mind in the rules when writing them. If someone’s access changes, you’ll have to revoke their refresh tokens.