Replies: 1 comment 1 reply
-
It's possible that the backend validation is expecting a claim that isn't present in the second token. Are the token payloads identical, or are there claims that are available in the token obtained using MSAL 1.4 that aren't available in the token obtained using MSAL 2.0? To answer your question, I don't believe there should be any differences in the token itself. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I'm testing MSAL 2.0 with Node.js and have reached a point where I am trying to authenticate with our existing Backend Server.
Our current MSAL 1.4 based front-end communicates with the backend using the provided Bearer Token with no problem.
My MSAL 2 test application appears to get the Access Token correctly from Azure following this guide
https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/acquire-token.md
However the backend rejects the token as
"statusCode": 401,
"headers": {
"www-authenticate": "Bearer error="Invalid token"",
I'm wondering if anything has changed in the token other than the front-end methods of obtaining it?
Beta Was this translation helpful? Give feedback.
All reactions