[FEATURE REQ] Authentication in a Stateless API using the Microsoft Graph API

[fgoulet]

We have an Angular 10 application that use MSAL Angular library to authenticate with Azure AD. We need a Spring Boot Rest API
that will accept IDToken v2 from the angular app. So our rest api must use the Microsoft Graph API. We also need that our rest api be configured for Stateless authentication.

I could not found any sample for this scenario. Is that cover by the this sdk ?

[joshfree]

Thanks for posting your question @fgoulet. @jialindai could you please assist routing this?

[chenrujun]

Hi, @fgoulet .

Stateless authentication is supported.
Please check related readme for more information.

[fgoulet]

Hi chenrujun,

Unless I'm wrong, Staleless is supported only for Azure AD endpoints, ID Tokens v1.0.

We need support for Microsoft identity Platform endpoints, ID Tokens v2.0, the one you obtains with Microsoft Graph.

You already have support for V2 tokens in your backend authentication (and state full) solution. We would need the same but with front end authentication.

[yiliuTo]

Hi @fgoulet just to make certain, we currently support backend authentication via both Azure AD (V1) and Microsoft identity Platform (V2) endpoints to Microsoft Graph API and Azrue AD Graph API. And your expectation is that we could support front end authentication in a stateless API using Microsoft Graph API on Microsoft identity Platform (V2) endpoints?

[fgoulet]

Yes, exactly.

[yiliuTo]

Hi @fgoulet . For stateless authentication with front end, we provide an AADAppRoleStatelessAuthenticationFilter using appRole instead of user group to implement authentication. The appRole feature of Azure AD requires additional configuration in the App manifest. Please refer to our sample for the detailed use.

[fgoulet]

Hi @yiliu,

This sample is for Azure AD endpoints with v1 id_token. Our Angular 10 application use the MSAL library that require Microsoft identity Platform endpoints with v2 id_token. AADAppRoleStatelessAuthenticationFilter decode v1 token only.

The difference is documented here

The v1.0 and v2.0 id_token have differences in the amount of information they will carry as seen from the examples above. The version is based on the endpoint from where it was requested. While existing applications likely use the Azure AD endpoint, new applications should use the v2.0 "Microsoft identity platform" endpoint.

v1.0: Azure AD endpoints: https://login.microsoftonline.com/common/oauth2/authorize
v2.0: Microsoft identity Platform endpoints: https://login.microsoftonline.com/common/oauth2/v2.0/authorize

[yiliuTo]

Hi @fgoulet , sorry I forgot to clarify it clearly in the last reply. The stateless authentication sample can work for both v1 and v2 id_token by specifying different sign in url in the index.html. And after replace the sighInUrl to Microsoft Identity Platform authorize endpoint you mentioned, the sample can obtain v2 id_token and verify the appRole claim.

[fgoulet]

Hi @yiliuTo ,
That's precisely what we do with our Angular app and we got this error when trying to access our Spring Boot Rest API
com.nimbusds.jose.proc.BadJWSException: Signed JWT rejected: Invalid signature

That could be related to this issue microsoft/azure-spring-boot#476

I think a complete working sample for this scenario is much needed.

[yiliuTo]

Hi @fgoulet , thanks for your reporting, and I am afraid not just a sample is needed here, but our AADAppRoleStatelessAuthenticationFilter cannot cover your case currently. This is because the stateless filter needs to parse the roles claim in tokens, however, in your case if the spring boot rest API needs to access Microsoft Graph API, then it requires an access token which doesn't contain the roles claim under this circumstance, that's why the error of Signed JWT rejected: Invalid signature occurs.

And if your spring boot rest API doesn't use Microsoft Graph API but has own logic, then you can modify content of the scope parameter with {your-client-id}/.default, which our stateless filter can work for you.

For your feature request, we could have a further discusstion. What do you think if we replace the checking for AppRole to scope in the stateless filter to meet your requirements, given this claim appears on both id and access tokens all the time? Or if the scope checking is not fine-grained enough, you could consider using the on-behalf-of flow to acquire an access token to Graph API on top of the stateless filter.

[fgoulet]

Thanks @yiliuTo , your explanations make things a little more clearer. I realize that I do not have the needed knowledge right now to formulate a feature request that would fit our needs. I will do some more readings and I will get back to you hopefully with a meaningful request.

[yiliuTo]

@fgoulet Here are some docs about the scp claim in access tokens and on-behalf-of flow, hope these could help. Our team will discuss towards this feature request too.

[yiliuTo]

Hi @fgoulet , having discussed with our team, we put this feature that support OBO flow to acquire access tokens for Microsoft Graph API on top of the implicit flow in our roadmap. If you are urgent for the feature then I suggest that you could develop this yourself. Also PRs are welcome ^v^

[saragluna]

Hi @fgoulet, we've just released our new aad starter, please check this CHANGELOG.

Your scenario is close to our resource server accessing other resource servers case, which leverages the OBO flow of Azure AD.

Please check these references to see whether it fits in your case:

https://github.com/Azure/azure-sdk-for-java/tree/master/sdk/spring/azure-spring-boot-starter-active-directory#oauth-20-on-behalf-of-flow-web-apis
https://github.com/ZhuXiaoBing-cn/azure-sdk-for-java/tree/master/sdk/spring/azure-spring-boot-samples/azure-spring-boot-sample-active-directory-resource-server-obo

[fgoulet]

Yes, it looks like it cover our needs.

Thank you.