Auth0 authentication of single-page-app on a different domain than the api

Nikola Schou Source

I'm trying add Auth0 authentication to my single-page-app. My app is running under a domain, say, whereas the api used by this app is running under a different domain, say

I'm aware of this thread:

Single Sign On (SSO) solution/architecture for Single Page App (SPA)

and the auth0 articles and github repositories linked by here. But I have a feeling that my scenario is slightly simpler, as I don't necessarily want to have single-sign-on between several different single-page-apps. For a start I just want the seperation between the API and the app.

Here is what I have tried already:

I already started from the article React Login With Auth0 and downloaded the starter project. I can surely login without problems and it will leave me with an id_token in my localStorage containing a JWS issued by Auth0.

I can also login directly on (my FeathersJS API application) and I can see that during the OAuth redirecting process, the id_token token is magically translated to a feathers-jwt token issued by my Feathers application containing the internal ID of the user-object matching the auth0-ID. I also have implemented the logic used to map from the Auth0-ID to my internal ID. Furthermore all my Feathers hooks such as validation of token and population of the user are working.

What I cannot figure out is how to alter the react-application running under with an Auth0-token in localStorage, so that this token is translated to a feathers-jwt token by, in such a way that all succeeding API-calls automatically has the feathers-jwt token included so the API can validate the user and return the right data.

Any suggestions on how to proceed will be greatly appreciated.

A couple of more background details:

  • The api is built on node.js and featherjs (which basically is an extension of Express)
  • The single-page-app is built on ReactJS and is served by a simple Express server, but it could be served by any server that can serve static files over http. The single-page-app makes http-requests to the api to read data and perform operations.
  • The api has the following lines of code taking care of the authentication:

    const authentication = require('feathers-authentication');
    const Auth0Strategy = require('passport-auth0').Strategy;
        token: {
          secret: 'mysecret',
          payload: ['email', 'auth0Nickname'],
          issuer: 'mycompany'
        idField: 'id',
        shouldSetupSuccessRoute: false,
        auth0: {
          strategy: Auth0Strategy,
          domain: '',
          'clientID': 'xxx',
          'clientSecret': 'yyy'


answered 2 years ago JoĆ£o Angelo #1

If you haven't done so, you should follow this article (React Login with Auth0) to implement the authentication on your React application. If you already tried to follow it, update your question with specific issues you faced.

Even though you currently not need SSO, the actual implementation of the authentication in your application will not vary much. By using Auth0 enabling SSO across your apps is mostly enabling configuration switches.

Finally for a full reference with all the theory behind the security related aspects of your exact scenario check:

Auth0 Architecture Scenarios: SPA + API


The full scenario I linked too covers the most comprehensive scenarios where an API is accessed by a multitude of client applications that may even be developed by third-parties that do not own the protected API, but want to access the data behind it.

It does this by leveraging recent features that are currently only available in the US region and that at a very high level can be described as an OAuth 2.0 authorization server delivered as a service.

Your particular scenario is simpler, both the API and client application are under control of the same entity, so you have another option.

Option 1 - Leverage the API authorization through Auth0 US region only (for now)

In this situation your client application, at authentication time, would receive an id_token that would be used to know the currently authenticated user and would also receive an access_token that could be used to call the API on behalf of the authenticated user.

This makes a clear separation between the client application and the API; the id_token is for client application usage and the access_token for API usage.

It has the benefit that authorization is clearly separated from authentication and you can have a very fine-grained control over authorization decisions by controlling the scopes included in the access token.

Option 2 - Authenticate in client application and API in the same way

You can deploy your client application and API separately, but still treat them from a conceptual perspective as the same application (you would have one client configured in Auth0 representing both client-side and API).

This has the benefit that you could use the id_token that is obtained after authentication completes to know who the user was on the client-side and also as the mechanism to authenticate each API request.

You would have to configure feathers API to validate the Auth0 id_token as an accepted token for accessing the API. This means that you don't use any feathers based on authentication on the API, that is, you just accept tokens issued by Auth0 to your application as the way to validate the access.

answered 2 years ago Michael Rambeau #2

I had exactly the same problem as you, I wanted to authenticate a user from a single page application, calling the API located on an other server.

The official auth0 example is a classic Express web application that does authentication and renders html page, but it's not a SPA connected to an API hosted on an other domain.

Let's break up what happens when the user authenticates in this example:

  • The user makes a request calling /auth/auth0 route
  • The user is automatically redirected to the Auth0 authentication process (Auth0 login form to choose the provider and then the provider login screen)
  • The user is redirected to /auth/success route
  • /auth/success route redirects to the static html page public/success.html, also sending a jwt-token cookie that contains the user's token
  • Client-side, when public/success.html loads, Feathers client authenticate() method reads the token from the cookie and saves it in the local storage.

From now, the Feathers client will authenticate the user reading the cookie from the local storage.

I tried to adapt this scenario to a single-page application architecture, implementing the following process:

  • From the SPA, call the authentication API with a source query string parameter that contains the SPA URL. For example:
  • Server-side, in /auth/auth0 route handler, create a cookie to store that URL
  • After a successful login, read the source cookie to redirect the user back to the SPA, sending the JWT token in a cookie.

But the last step didn't work because you can't set a cookie on a given domain (the API server domain) and redirect the user to an other domain! (more on this here on Stackoverflow)

So actually I solved the problem by:

  • server-side: sending the token back to the client using the URL hash.
  • client-side: create a new html page that reads the token from the URL hash

Server-side code:

// Add a middleware to write in a cookie where the user comes from
// This cookie will be used later to redirect the user to the SPA
app.get('/auth/auth0', (req, res, next) => {
  const { origin } = req.query
  if (origin) {
    res.cookie(WEB_CLIENT_COOKIE, origin)
  } else {

// Route called after a successful login
// Redirect the user to the single-page application "forwarding" the auth token
app.get('/auth/success', (req, res) => {
  const origin = req.cookies[WEB_CLIENT_COOKIE]
  if (origin) {
    // if there is a cookie that contains the URL source, redirect the user to this URL
    // and send the user's token in the URL hash
    const token = req.cookies['feathers-jwt']
    const redirectUrl = `${origin}/auth0.html#${token}`
  } else {
    // otherwise send the static page on the same domain.
    res.sendFile(path.resolve(process.cwd(), 'public', 'success.html'))

Client-side, auth0.html page in the SPA

In the SPA, I created a new html page I called auth0.html that does 3 things:

  • it reads the token from the hash
  • it saves it in the local storage (to mimic what the Feathers client does)
  • it redirects the user to the SPA main page index.html

html code:

  function init() {
    const token = getToken()
    if (!token) {
      console.error('No auth token found in the URL hash!')
    // Save the token in the local storage
    window.localStorage.setItem('feathers-jwt', token)
    // Redirect to the single-page application
    window.location.href = '/'

  // Read the token from the URL hash
  function getToken() {
    const hash = self.location.hash
    const array = /#(.*)/.exec(hash)
    if (!array) return
    return array[1]


And now in the SPA I can use the Feathers client, reading the token from the local storage when the app starts.

Let me know if it makes sense, thank you!

comments powered by Disqus