I’ve read through a chunk of the docs and am not fully following one concept.
We currently have a “regular web application” client, and users log in with the Resource Owner flow (hitting /oauth/ro). We get an ID token back, and an opaque access token.
Question 1: How would I take this setup and gain access to an Auth0 API, allowing the API to have a JWT that tells the Auth0 USER’s identity (not just the Auth0 client info).
Question 2: Can I assign scopes to a USER (not the Auth0 client)? I have 3 user types in the same Auth0 Client. I’d like to say User A can have a read scope on an API and User B can have a read/write scope and User C can have read/write/delete scope. From what I’ve seen scopes are defined on the Auth0 CLIENT (not user).
1.
If you want to start using API Authorization functionalities you need to use authentication endpoints that support it. API Authorization functionality was introduced as part of a broader goal of aligning the authentication endpoints with the OpenID Connect specification so it’s not available on legacy endpoints that already existed even before the final version of that specification. You can read more about this here.
Of particular interest to your scenario, you would move from /oauth/ro endpoint to the /oauth/token endpoint which also provides the ability to execute a resource owner password credentials grant, but does so with additional support for API Authorization. With this endpoint you will get a JWT access token valid for your configured API.
If you need to add custom claims to the access token check this relevant documentation.
2.
For client applications that request access tokens on behalf of the application itself and not of end-users (aka client credentials) you can manually assign scopes to the individual client applications. This works well given the number of client applications is in general small.
For users, manual assignment would not scale so you can instead assign/restrict the scopes granted to a user for a given API through the use of a rule. In your case the rule would take in consideration the user type and assign scopes accordingly. You can use context.accessToken.scope in your rule to control the exact scopes issued as part of the access token.
This is extremely helpful. Thanks @jmangelo
Quick follow-up. We are hitting /oauth/ro based on an Ionic 2 quickstart, which used the Auth0 Lock JS, which hit this endpoint. I see that quickstart has now drastically changed to use PKCE.
Given that this is our current state, would we be able to have the user to log in via /oauth/ro, and then hit this resource owner password credentials endpoint with something other than the username & password? Effectively trade in a token to get an API access token? We wouldn’t use JS to make this call since the secret is involved.
At this point, to my knowledge, the /oauth/token can exchange username/password credentials or a refresh token obtained previously at this endpoint for access tokens meant to call an API. This implies you would not be able to mix usage of /oauth/ro and this endpoint.