Clarifying use case scenario in documentation

[cheslijones]

Reading through the documentation scenarios here and identifying the correct scenario for my use case:

1. User accesses the microservice ReactJS front-end where react-aad-msal directs them to login with their Azure AD credentials.
2. They successfully login and receive id_token and access_token.
3. The access_token needs to be sent from the microservice ReactJS FE to my microservice Django/Django-REST-Framework (DRF) API.
4. The Django/DRF API needs to verify the authenticity of the access_token against Azure AD as well to grant communication between the FE and the API, to make sure some garbage string wasn't sent to it from the FE.

This use case leads me to believe that the "Web Application signing in a user and calling a Web API in the name of the user" is correct scenario and that this documentation found here is what I should be following to work on the Django.

That being said, all I'm really trying to do is validate the authenticity of the access_token sent over from the FE. I came across this documentation related to that.

So I'm unclear from the documentation what I should be trying to implement here with this library: the "The web app that calls web APIs" scenario or just the token validation method.

Can someone offer clarity on this?

[rayluo]

There are 2 roles in: web app ---- calls ----> web api

This MSAL library helps the former i.e. web app to obtain a token.

Your DRF backend sounds like the latter i.e. web api who needs to validate that access token. We do not currently support that. A feature request is recorded at #147.

[cheslijones]

There are 2 roles in: web app ---- calls ----> web api

This MSAL library helps the former i.e. web app to obtain a token.

Your DRF backend sounds like the latter i.e. web api who needs to validate that access token. We do not currently support that. A feature request is recorded at #147.

That is correct: DRF receives the access_token from the ReactJS FE. DRF is strictly the API, it serves no static assets and should not have an authentication process on its own. It should not be accessible except by the ReactJS FE. This, at least, is my understanding of how a modern microservice web application should work.

Any time frame for having the feature added? Looks like January is when it brought up.

[rayluo]

To be honest, there is no specific timeline to be shared at this moment. But it doesn't harm if you can add a thumb-up reaction on that issue for our future planning purpose, and then you also subscribe that issue so that you will be notified when we get back to that one eventually.

[rayluo]

Updated the first link used by @cheslijones at the beginning of this issue. Closing the doc issue here, and keep track of the feature requirement at #147.