Auth0 Home Blog Docs

Am I an API or a web app?



I’m a little confused as to the terminology used by Auth0. I have a Java / Spring app that persists data to a database. The only way to get data in and out is through a REST API that is built with Spring MVC. I think of the combination of these as the backend. Users interact with pure javascript built in React / Redux which connects to the backend through Thunk middleware. Obviously these tools are very comfortable with API keys and secrets. The confusing part is I have no intention of ever making the API public, it exists to support the javascript UI and REST is just a convenient way to do that.

My question is: given this architecture, should I be telling Auth0 that I am a normal Java web app? Or should it be 2 clients - one for the API and one for the React app?


I would recommend using API Auth for this flow as your API is a First Party Resource Server. You can disable Dynamic Third Party registration and use the API only for first party. However, the resource server flow is better suited for your requirements due to the following reasons.

  • Access tokens contain authorization information, your API can use them to restrict access to resources etc.
  • No need to delegate a token in order to access your API (the delegation feature will be deprecated in future).
  • Using silent authentication etc to extend the session in your application.


@abhishek.hingnikar @pswartwout I’m facing the same questions.

Successfully got my client side React application enabled with auth0 providing user access.

I want to then utilise that token (and the various authorization meta data like you mentioned) and then pass it on to my backend API (Java Spring Boot based) which will have ALL routes secured and will take actions based upon the authorization data passed through the token.

There seems to be various auth0 and spring boot tutorials but given the scenario above which is the best article for us to follow?


Have you looked at


Just following it now.

The README here:

Points to a failing link:


I’m still not fully understanding the flow here.

So my SPA is currently authenticating against my Auth0 SPA client and working successfully. Do I then pass my token, granted by the SPA, on to the Spring API?

I’ve tried this using a cURL request to get token like so:


with username, password and client ID parameters.

Then used the subsequent id_token to make a second cURL request to my API like so:

curl -X GET -H “Authorization: Bearer {{ID_TOKEN_VALUE}}” -H “Content-Type: application/json” -H “Cache-Control: no-cache” “http://localhost:8080/some/url


Ok reading through docs here:

We get the id_token from the SPA then we make a subsequent request to get an access token for calling the API.

We then pass the access token over to the API.

The API can then use the access token to make further calls to obtain user data.


@james.heggs Thanks for blazing a trail. I haven’t had time to get back to this but I will this weekend. It sounds like the short answer to my original question is “it’s both”.


No problem - for once the vast amount of documentation is confusing not knowing whether its deprecated or the correct way of doing things. For example I’ve now found this:

Which documents using delegation but I’ve also read that its the old way of doing this.

Also I can’t see any code examples showing how to obtain user data from access token when within the API code base. All in all pretty confused.


The document I linked assumes you are using access tokens fetched from completing one of the flows at we have been recommending using access tokens over id_tokens for calling API’s once you can describe your resource server at you can set up the example you linked. Beyond that your client should complete an OIDC Complaint flow to fetch an access_token, that it can use to call your API.


That is correct, delegation is being phased out for APIs is more accurate. The is outdated as it has been enabled for all tenants out of the box.


James, have a look at the “Related Question” in the box to the right titled “How to login a SPA …” I think it should help.


Yeah it helps a little thank you.

Still lacks the depth of a full example and doesn’t show the code for performing the authorize request after the user has successfully logged in.

It seems such a common workflow that I’m a bit surprised that there isn’t a standard example for this in their documentation. The auth0 docs are usually so good!


@pswartwout How did you get on?

I’ve had no luck with getting things up and running successfully.


Sorry, I’ve been very busy with my day job and haven’t come back to this yet. When I do I will comment here.


@james.heggs See my reply to I’m getting closer but using Lock to do the authentication is causing me grief.


Morning @pswartwout thanks for the update - I went direct in to Auth0 support and had them look over my code a little to help.

So it turns out that this flow isn’t currently supported by the AuthJS custom login way of doing things (which is what I was doing!).

They advised to use the hosted login option or lock (similar to what you’re doing)

I’ve not had chance to come back to it yet and try that route but reading your comments it looks difficult also.