I am trying to use access tokens to authenticate to a backend (django rest framework) API. My java script frontend (VUE.JS) displays the lock and saves an access token and jwt token in localstorage.
I would like to not send the JWT over the wire to the backend, but instead send the access token, and have the backend retrieve the user profile information itself when and if it is needed.
Testing using postman GET with an authorization header - /userinfo returns only the ‘sub’ key of the profile.
Testing using postman POST /userprofile sending the jwt as the body returns the full user profile.
So: If the browser authenticates the user and gets an access token, and I send it to the backend, how should the backend retrieve the users profile. I need to grab:
…
I have read some more and am beginning to understand what the parts of this are. However, I am looking for a simple example which:
1 SPA Vue application displays some information from the logged in user’s profile (their name, or email, or…)
2 The SPA sends the access-token to a server to authenticate the user, and the server can get information from their profile namely the sAMAccountName
I am pretty sure I can do this with ‘rules’ but am a bit lost in the details.
You need to take in consideration that you can use the Auth0 service for user authentication (following OpenID Connect or other protocols, but OIDC is the most commonly used) and for API authorization (following OAuth2).
In user authentication (OIDC) you will in general get an ID Token (always a JWT, because the spec says so) and also possibly an access token that can be used to obtain information about the user identity that just completed the authentication step. This access token when issued only in the scope of OIDC is both consumed and issued by endpoints that are in control of the same entity (your Auth0 tenant) so it can use a token format based on a unique random value (opaque token, currently around 16 characters) that is then used as a lookup in internal database as validation/processing mechanism.
If you then bring API authorization into the mix (aka the audience parameter) you can perform an initial request that will be satisfied both in terms of user authentication and also API authorization. In this scenario, if you request an ID token it’s issued exactly as if this was just a user authentication request. However, for the access token, things will be different; it will be currently issued in a JWT format so that your own API can validate it without additional calls. In addition, if the API is configured to use RS256 the access token will have not just your API audience, but also the audience associated with the /userinfo endpoint which means the access token can actually serve double duty (call your API and the user information endpoint).
In conclusion:
you must not send ID tokens to your API as a method of authorization.
you must not send access tokens only meant for the /userinfo endpoint to your API as a method of authorization.
you should request an access token meant for your own API and use that one instead; if you need more information about the user then the included by default (which is just the user identifier) then you can include additional information in the access token through the means of custom claims.