2

We currently use the following authorize url: https://login.microsoftonline.com/common/oauth2/authorize?resource=https%3A%2F%2Foutlook.office365.com

We want to also use the Graph API, so I added the following: https://login.microsoftonline.com/common/oauth2/authorize?resource=https%3A%2F%2Foutlook.office365.com%2F%26https%3A%2F%2Fgraph.microsoft.com

I've tried different delimiters between the two resources, but couldn't get it to work. Each one resource works separately. I hope that more than 1 resource at a time is supported?

Rohit Saigal
  • 9,317
  • 2
  • 20
  • 32
Tanya Kruglikova
  • 53
  • 1
  • 5

1 Answers1

3

I think what you're trying to do here by passing multiple values to resource parameter directly will not work (probably not a supported scenario, but I'll wait till someone from Microsoft confirms or I find Azure AD documentation stating exactly that. In the meanwhile, here's an old blog post that says something like this, but it's a blog talking about SSO and old from 2014 :), so don't want to rely solely on this.)

Below I'm explaining how you can make this scenario work by reusing refresh tokens and without passing both resource ids in same call. (NOTE: This approach will work for Authorization Code Grant Flow but not for Implicit grant flow like a JavaScript based SPA, because no refresh token is returned in that case)

  • Once the authorization code is available from authorize endpoint, you go to Azure AD token endpoint requesting token for a single resource (using REST call to endpoint or something like ADAL library AcquireToken method depending on your application requirements)
  • You get back an access token + refresh token as a response to your call to token endpoint. The access token is valid for resource that was mentioned in first call (say graph.microsoft.com)
  • Then using refresh token you just got, you make another call to token endpoint (REST or ADAL AcquireTokenSilent so that there isn't a popup to ask for user credentials this second time) and get a token for the second resource by specifying the 2nd resource id in case of this call
  • The access token you get this time is valid for the 2nd resource.
  • In fact you can continue doing this and hence the name Multi-resource refresh tokens shows up in some places. Although now all refresh tokens are supposed to be multi-resource or valid to be used for requesting any resource that your application has consent for.

Links that can help you in understanding further and implementation

Rohit Saigal
  • 9,317
  • 2
  • 20
  • 32
  • Thank you @RohitSaigal, this is all great information, but unfortunately we already have a flow, and it wouldn't be easy to change it to request another access token for a 2nd resource, and then to keep track of two different access tokens, and then to know which one to use at which time. If you can find any official information from Microsoft , that would be very helpful. – Tanya Kruglikova Oct 13 '18 at 01:42
  • @TanyaKruglikova I understand. I found a blog talking about something vaguely similar but not a Microsoft documentation. Hopefully I just don't know about a way to do this yet and we both will learn something new :) – Rohit Saigal Oct 13 '18 at 01:48
  • Also, I'm wondering since https ://login.microsoftonline.com/common/oauth2/v2.0/authorize doesn't require a resource, can i try using that? will the token work for both resources? – Tanya Kruglikova Oct 13 '18 at 01:58
  • v2.0 endpoint is for Azure AD B2C.. It does support multiple scopes instead of the concept of resource.. but you can only use it if you're planning to move your application to B2C. There are differences between Azure AD (v1) and Azure AD B2C (v2).. https://learn.microsoft.com/en-us/azure/active-directory/develop/azure-ad-endpoint-comparison – Rohit Saigal Oct 13 '18 at 02:02
  • Rohit thank you, I've read this, but it didn't say explicitly that I can't mix scopes from microsoft graph and outlook.office365.com. I tried 2.0 endpoint, and I can get access to graph, but not outlook.office365.com I read this post: https://stackoverflow.com/questions/38150335/microsoft-graph-scopes-v2-oauth and response from @JasonJohnston confirms that you can't mix the scopes. I'm looking for some workaround to use (besides what you've suggested, which requires lots of code changes), either with v1 or v2.0 endpoints. – Tanya Kruglikova Oct 13 '18 at 03:24
  • @TanyaKruglikova I am only trying to tell that V2.0 endpoint will work for applications registered with Azure AD B2C. Azure AD B2B (v1) and Azure AD B2C (v2) are completely different versions with major distinctions in what they support v/s not.. You will need to move your app registration and may impact your current users.. if you feel moving to B2C is something that's acceptable, it might help with this particular problem of token with multiple scopes.. Just take an informed decision and read a bit on differences that's all.. I am not aware of a workaround with v1, but will look.. Good luck! – Rohit Saigal Oct 13 '18 at 03:55
  • @TanyaKruglikova, Rohit's answer is correct. The way to do what you're trying to do is to use the refresh token you get during the initial token request to request an access token to the second resource. One access token only works for one resource. There is no reason this should add *any* complexity to your code. ADAL (or MSAL), takes care of managing the tokens, keeping track of which token is for which resource, and, when needed, requesting additional access tokens for new resource. All you do is tell it "please give me a token for resource X", and the library does all the magic. – Philippe Signoret Oct 14 '18 at 16:29
  • @RohitSaigal, The v2 endpoints is *not* exclusively for Azure AD B2C! The v2 endpoint works just fine with "regular" Azure AD (what you are calling "B2B", though that's also incorrect). – Philippe Signoret Oct 14 '18 at 16:31
  • @TanyaKruglikova, if you can share the platform your developing for, and the code you're using now to sign in and get that first access token, it'll be easier to give you a more complete answer. – Philippe Signoret Oct 14 '18 at 16:32
  • @PhilippeSignoret Thanks for going through the answer/comments and the information you provided here. I didn't know about use of v2 endpoint from "regular" Azure AD. That sounds interesting and I'll read up on that. – Rohit Saigal Oct 14 '18 at 18:12
  • @PhilippeSignoret thank you for your answer, do you have a link where I can find more details on using ADAl or MSAL for managing tokens? The reason I say this requires a lot of changes to our own framework is I'm not sure that we're using either of this, but I'm meeting with a developer from another team to double check tomorrow. So far, we haven't had need for it, since we had only 1 token/1 refresh token at a time. – Tanya Kruglikova Oct 15 '18 at 18:08
  • @TanyaKruglikova The general reference is here: https://learn.microsoft.com/en-us/azure/active-directory/develop/, but if you can share the platform you're developing for, and the code you're using to request tokens today, we can point you to the specific library to use. – Philippe Signoret Oct 15 '18 at 18:29
  • Thanks @PhilippeSignoret and Rohit Saigal. We decided that we're going to use the name/email stored in the token itself, since that's all I need to get. It doesn't make sense to change our authentication flow to just be able to use both APIs. In the future , though, we might consider using both (EWS and Graph). – Tanya Kruglikova Oct 17 '18 at 02:55
  • In v2.0, use the scope parameter of a token refresh request, to get a new access token for a different resource. E.g. a scope of `https://graph.microsoft.com/User.Read`, if the initial request was scoped for outlook.office365.com. See details in [my answer to a similar question](https://stackoverflow.com/a/68226072/2606359) – sudoqux Jul 02 '21 at 13:46