3

I have a number of angularJS application that access a number of nodeJS hosted API's. and I would like to replace the bespoke authorization framework with Azure AD implicit grant (long story how I arrived there ..)

Currently going through a POC (based on Microsoft example ) and have hit a problem with obtaining a single access token to be used against number of API's

Both ui's and API's have been registered with AZURE AD Application. Also have configured a number of permissions so they are authorized to call the API's e.g. https://graph.windows.net/User.Read api://xxx-xxx-xxxx-xx-xxxx/sales.admin

I then define in the client 

var requestObj = {
    scopes: ["https://graph.windows.net/User.Read", "api://xxx-xxx-xxxx-xx-xxxx/sales.admin" ]
};

So naively I thought I will be able to get an access token that I can use against multiple API's

However, looks like that is not the case. The client app has to create separate access tokens for each API the application needs to access.

Is this right ? This adds lot's of complexity on the client as it needs to maintain and refresh those tokens.

Am I missing something on the 'architecture' e.g. API Management layer ?

Thanks

Nick

nick
  • 1,431
  • 2
  • 11
  • 9

1 Answers1

5

This is correct. An access token only works for a single API.

The reason is that each token specifies its valid "audience" (stored in the aud claim). This identifies the intended target (API) of the token.

Also, MS Graph API uses an entirely different signing algorithm to other APIs, and so would not be able to even be in the same token anyway.

APIs can set various settings in their manifests that affect the tokens in various ways. This also makes it quite impossible to have one token that would work on all APIs.

If you wish, you can simplify it for your client by creating an "API gateway", which proxies the calls to the right APIs with the right tokens. This gateway would handle the complexity of tokens then instead of the client, which would only need to authenticate to the gateway. Look into On-behalf-of grant flow to see how the gateway can call APIs as the signed-in user.

juunas
  • 54,244
  • 13
  • 113
  • 149
  • Thanks I am trying to avoid implementing the on-behalf of pattern ... I think I will try and remove the link to Microsoft graph API and try again ... – nick Jan 27 '20 at 14:05
  • I think it is currently not fully correct (any more?). It seems like I am able to obtain a token valid for both the "User.Read" Microsoft Graph API and Azure DevOps API (https://app.vssps.visualstudio.com/user_impersonation). Combining that with Kusto (access to Azure Data explorer) fails, though. – Michael Kopp Oct 14 '22 at 11:43
  • @MichaelKopp did the token work for both the MS Graph /me endpoint and a DevOps API endpoint? – juunas Oct 14 '22 at 11:48