In the SPA + API architecture scenario (Single-Page Applications (SPA) with API), using a framework like VueJS or React against a REST API, I believe I understand that it is the responsibility of the SPA to authenticate the user against Auth0. In doing so, the SPA will receive back an Access Token (a JWT I suppose). The SPA then must include that JWT in the Authorization header of HTTP requests to the REST API.
The API would then need to validate the token in various ways, most importantly that it hasn’t been tampered with. I believe that, since Auth0 issued the token, the API application would need to use the AUTH0_DOMAIN (issuer) and AUTH0_CLIENT_SECRET (signing secret).
You need very little information from Auth0 to validate an access token, and that information is available from the .jwks endpoint. It should be cached to avoid hitting Auth0 each validation.
Hi @john.gateley - thank you for the links. I definitely will go read all of that carefully. But, I need a better mental model of how this all should work first. So, if you’ll indulge a couple more questions, that would be very helpful.
As a reminder, the context is an architecture where there is a VueJS (or React/whatever) client-side application talking to a REST API (in my case, implemented in Phoenix).
Please confirm or correct the following assertions:
#1 - the VueJS application would be responsible for interacting with Auth0 to accomplish user authentication - without the REST API being involved at all
#2 - if #1 is successful, the VueJS application will be supplied by Auth0 with an Access Token (and optionally an ID Token per the Implicit Grant section of Solution Overview (SPAs + API))
#3 - the VueJS application would pass the Access Token in the Authorization HTTP header in subsequent calls to the REST API
If all of the above is basically correct, I think my main question remains how does the API know that the token that was passed in the Auth header is one it should trust?
#4 - I think what you’re saying is that (assuming the JWT was signed with an asymmetric algorithm like RSA 256) the API can obtain the public key from the jwks endpoint (per Locate JSON Web Key Sets) and generate a new signature for the JWT to compare it to the one in the JWT.
First, if you have a SPA that has a single (or primary) REST API for a backend, my recommendation is that you treat this as a classic web app and use Auth Code Flow:
This is more secure, as the access token never reaches the browser (SPA).
If not, ensure you are using Auth Code + PKCE. See this doc:
And then, your point #4 is correct, though I recommend using an SDK that will perform the work (incuding signature verification and caching and all the other steps of token verification).
Thank you, John. I appreciate the recommendation on approach and rationale. As I’m using Phoenix on the server side, I can use Guardian or another of the JWT libraries listed for Elixir on jwt.io for the token verification.