But the middleware should be reaching out to the OpenID Connect document to fetch the issuer, and public key for certificate to validate the signature on the token. I am not sure, what is that middleware in case of Springboot. Net framework Owin is the middleware used to validate and authorize the tokens. MSAL.js library helps in fetching the tokens from AAD. To authenticate against AAD and get a token from it and then make the backend API call, the front end app has to follow the client_Credential flow of OAuth to achieve this. Now the second part is suppose this frontend app has to call the api on its behalf, in that case, the frontend app has to authenticate to AAD to get a token to access the backend API. Usually since its a React.js application it would be using Implicit flow (is using MSAL.js v1.0) or it can also use Authorization Code grant flow (if using MSAL.js v2.0) This is one part. Once user enters his creds and authenticates himself/herself to AAD, AAD issues a token to the user to access the ReactJS frontend app. In this scenario, when the user accesses the ReactJS frontend app, he has to first get himself/herself authenticated to AAD to access the frontend app.
Suppose you have a front end app coded in React.JS and you have a backend WebApi coded in Springboot and both are protected by AAD (registered in AAD). To clarify my words, I would like to state a scenario for better understanding. Also, please do not forget to accept the response as Answer if the above response helped in answering your I apologize for the delay in my response. This sample uses MSAL4J and OpenIDConnect protocols and also it would show the implementation of calling a Graph API where the token validation happens.ĭo let us know if this helps and if there are any more queries around this, please do let us know so that we can help you further. Since using SpringBoot application, I would suggest you take a look at the following sample. This is how a resource setting accessTokenAcceptedVersion in the app manifest to 2 allows a client calling the v1.0 endpoint to receive a v2.0 access token. Issuer and Audience fields are populated in the token by the Microsoft Identity Platform when it is issuing the token and the same information resides in the OpenID Discovery Endpoint also.Īccess tokens are created based on the audience of the token, meaning the application that owns the scopes in the token. The issue should not have /v2.0 and you should not think that if you care calling the OAuth2.0 endpoints the issuer would also have v2.0 as /authorize or /token are endpoints that AAD provides and they can be either v1.0 or v2.0 but that is totally different from the value of the issuer field in the token. Now the issuer value is usually same as the one mentioned in the OpenID Discovery Document. This validation happens against the OpenID discovery document.
Ideally when validating an access token comes into picture, the audience, and issuer mostly validated.
0 kommentar(er)
