I have a SPA application (.NET) successfully authenticated with Auth0 through the management Api. In the logincallback.ashx I request a token like this:
Where domain and apiIdentifier match the Managmenent Authorization Api. If I pass that token using PostMan the authorization doesn’t work.
However, If I create a new Api in Auth0 and generate a token with the test tab and configure my apiIdentifier according to this new Api in Auth0 it works fine.
What am I missing here ? How can I validate the token issued to the SPA application in my API?
If a SPA wants to be issued an access token meant to be used in call to an API then it needs to specify those intentions (using the expected audience value) when doing the initial authentication/authorization request.
If you haven’t done so already you should read the following documentation:
Hello Jmangelo,
Thank you for your response. I understand that. But what happens in my application is that I will have multiple Apis being called by an user that will authenticate only once. Do I have to request a different access token for any one of them? And in that case, how can I implement that?
+1. I’m currently stuck in the same situation. We currently are using the (now deprecated) delegation method to get tokens to use for multiple APIs from our SPA. However, after reading through the linked documentation, it seems like we’re going to have to have a bunch of silent redirects if we want to talk with several backend APIs and not have the user go through an approval process for each one. More light on this situation would be very helpful.
Hello Jmangelo,
Thank you for your response. I understand that. But what happens in my application is that I will have multiple Apis being called by an user that will authenticate only once. Do I have to request a different access token for any one of them? And in that case, how can I implement that?
+1. I’m currently stuck in the same situation. We currently are using the (now deprecated) delegation method to get tokens to use for multiple APIs from our SPA. However, after reading through the linked documentation, it seems like we’re going to have to have a bunch of silent redirects if we want to talk with several backend APIs and not have the user go through an approval process for each one. More light on this situation would be very helpful.
Even though it’s redirect-based this would be somewhat similar to having to perform various AJAX calls to exchange tokens. What would be the main difference that impacts your scenario?
If all the API’s are under your control you can consider if representing them as a single audience is a suitable alternative; see https://auth0.com/docs/api-auth/tutorials/represent-multiple-apis. Otherwise, you’ll have to request an access token for each API, however, depending on the configuration it’s possible to perform this additional requests without the user having to authenticate again so it would be transparent for the end-user.
I Accept previous answer for the following post by jmangelo:
If all the API’s are under your
control you can consider if
representing them as a single audience
is a suitable alternative; see Configure Logical API for Multiple APIs.
Otherwise, you’ll have to request an
access token for each API, however,
depending on the configuration it’s
possible to perform this additional
requests without the user having to
authenticate again so it would be
transparent for the end-user.
Thank you very much, that suits my scenario perfectly.
Am I missing something where this is simple? For us, if we want to talk with 5 different APIs, then this means that we’ve got to redirect to 5 different screens to get approval. Under the old delegation method, we could just make AJAX calls and it would be invisible to the user. This is an extremely annoying thing if we have to go to 5 different UIs via redirects.
You can configure the API to Allow Skipping User Consent which means that consent screen is not shown to first-party application (which is most likely your scenario). This results in the request being transparent to the user because they don’t have to do anything given the requests complete using a previous authenticated session.
Have in mind that consent screen is always shown if you’re trying this in a application hosted in localhost, however, even for development you can quickly remove the use of localhost so that you can see the expected behavior.