Hi,
My scenario: SPA, Resource API & Authorization extension API.
How do you retrieve a access_token for the auth0-authorization-extension-api? I’ve tried sending an array of audiences (resource & urn:auth0-authz-api) when authenticating the user but this doesn’t seem to work. I would have expected this to work as an array of audiences is supported in the access_token?
Any help would be great.
Thanks
Does anyone have any feedback on this question to help resolve the problem?
I’ll need to check what are the possibilities we have for multiple resource servers. Off the top of my head I don’t believe we support it during the request phase, but I’ll double-check and keep you posted.
ok thanks, if multiple audiences aren’t allowed then a solution to how we could support the scenario above would be useful without having to ask the user to authenticate twice.
any update on this question? its currently a blocker for us moving forward with Auth0
Multiple audiences are not supported during the request; could you address your scenario using the client credentials grant for the extension and the audience parameter for your resource server?
Hi, our scenario is using a SPA so client credential grant is not viable. Does the extension not support SPA? Does that mean we have to authenticate twice if we want an access token for the resource & extension? Is multiple audiences being supported on request in the future?
After further testing if we specify the extension as the audience then we get a token back that can be used for the extension.
Unfortunately we are still stuck with the same problem of not wanting to authenticate the user twice and use both API’s with one token.
This seems to be a gap in functionality as it would be a common architecture to connect to multiple API’s with one token?
For multiple API’s under your own control there are alternatives like representing them all as a single resource server. For the case where the API’s have mixed ownership this would not be applicable, however, I think the scenario you described should not be tackled by granting access tokens directly to end-users. Given that the extension API performs account management I would go for client credentials even if that implies having access from a SPA brokered by a middle-man.
Hi Jmangelo,
All of those options seems like a workaround really, ideally you shouldn’t have to combine all your API into one resource or add a middle-man process.
Do you know whether multiple audience for requests is something that can be raised as an improvement as its supported in the response access tokens?
(this is a summary of the discussion in the comments and an answer to the improvement request comment)
Currently, it’s not possible to perform a single request that includes multiple audiences. With some constraints, that scenario is not completely unfeasible and I’ve already seen internal conversations mentioning it so this is something that already has been considered. However, at this time, it’s not supported and I can’t provide you with any definitive outcome/timeline in relation to that possibility.
As alternatives (or workarounds if you prefer) you can for API’s that you control represent them as a single resource server or perform multiple requests with different audiences. If the user authenticated in a way that it established a session with Auth0, then the user will not have to explicitly specify their credentials for the subsequent request. If the individual API’s require consent then yes, the user would need to provide consent each time.
In relation to the specific scenario in question which is related to the API made available by the Authorization extension I would still recommend the client credentials grant (for non-confidential clients, this would indeed require a broker service). The reasoning is that the functionality exposed by that API is sensitive enough to warrant the consideration that is possibly for the best to not expose access tokens directly to end-users and instead go through a broker. This part is mostly my personal opinion, although I believe the extension API will reject tokens not obtained through a client credentials grant.
To clarify, to implement our scenario we must:
Create client for SPA & Resource Server (Non Interactive)
Create API for Resource Server, Auth0 Management API & auth0-authorization-extension-api
This would allow the SPA to authenticate (using audience) against Auth0 to retrieve an access token to communicate with the Resource Server. The Resource Server would then authenticate (using client credential grant) against Auth0 to request a access token to communicate with the Auth0 Management API & auth0-authorization-extension-api.
Please can you confirm our understanding is correct?
Yes, that is correct.