Auth0 Home Blog Docs

SPA app that queries my own server, rather than auth0 directly?

spa

#1

I am looking through the example React apps. They seem to query Auth0 directly via the Lock widget.

Are there any examples of a Single page app querying my own server, and then forwarding auth requests to Auth0?

What do I cache in local storage, the token I receive back from Auth0? What is the Auth flow type?

What do I configure my client as in Auth0, a single page app, or a traditional server side app?


#2

In general, single-page applications making use of OIDC/OAuth2 will interact directly with the identity provider/authorization server. The reasoning here is that given the result of the authentication/authorization process are tokens that the SPA will have to know about, most of the time there isn’t any benefit to go through a middle-man. The side-effect is that the available examples will also focus on this scenario so as far as I’m aware there’s not an available example for that concrete scenario.

Assuming the general flow would mean that within Auth0 the application should be described as a single-page application in terms of client application type and should also make use of the implicit grant as the preferred way to perform the authentication and obtain the tokens.

Since it’s highly likely that this application will require performing authenticated calls to a back-end service in order to be useful, the way you would represent this in Auth0 would be to also have your back-end service as a know entity, more specifically to configure it as an API within the Auth0 Dashboard.

This would allow the SPA to request user authentication and an access token valid to your back-end API. After obtaining the access token, the application would store it locally (local storage is probably the most widely used approach) and then include the access token in each call to the back-end API. The authentication response may also include an ID token, the application would use this to customize the UI to reflect the user in question, but caching the token itself is not generally useful as you won’t be making any requests with it.


Having said that, an alternative to this common scenario would be if your back-end service is highly coupled with the SPA application and is available/deployed under the same domain. In this scenario it should be feasible to make use of a cookie-based session that is bootstrapped by the ID token resulting of the user authentication. However, this is generally associated with the more traditional server-side web application and as such you may not find many example that use this approach while also making use of SPA frameworks.


#3