-
Notifications
You must be signed in to change notification settings - Fork 21.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SPA usage does not work, due to CORS #39201
Comments
@kyubisation Thanks for your feedback! We will investigate and update as appropriate. |
Hi, We faced a similar issue, Implicit Grant is too old now. So we chose Auth0 and then will move to Okta later. Will keep an eye on MS Identity 2.0, I think it has some good features coming out in the future! |
I can provide a minimal reproduction, if that helps in your investigation. |
@hpsin, mind taking a look at this one? Thanks. |
We don't support CORS/authz code flow for SPA yet. We're investigating support currently. That said, we have appropriate controls in place that you can securely use the implicit flow - many of the issues described in the RFC fall under the category of "poorly implemented IDP", and are issues that we protect against. |
See this for more details #please-close |
That is a bit disappointing. The MSAL.js library does not seem mature enough, looking at the roadmap and some of the issues. So we would have preferred to use a more mature standalone OIDC library. |
Appreciate the feedback. Could you reach out to me directly (hirsin at microsoft) to discuss the problems with MSAL.JS and the problems you hit? I own OAuth at Microsoft, so want to shortcut the official channels that eventually lead to me anyway. Enjoy your holiday! |
Thank you for the heads-up. |
@hpsin As usual the problem is between keyboard and chair. I supplied the wrong parameter to response_type, instead of letting the library handle it (we are using angular-oauth2-oidc). I fixed that and it now works as expected with the implicit flow. To further explain our preference of using a standalone OIDC library; We are using both AzureAD and RedHat SSO in our organization. If we can use the same library for both AzureAD and RH SSO, we can reduce our internal support effort. As for the MSAL.js library; We will wait and see how the Angular integration will be implemented. Afterwards we will make a final decision on how we proceed. We are of course also looking forward to the implementation of AzureAD/microsoft-authentication-library-for-js#1000 😃 |
Gotcha, glad it's working. We're OIDC compliant, so you should definitely be able to use any library you like and cut down on duplicates (until you want to support conditional access etc.). Unfortunately we can't guardrail this error case, it would be nice to indicate that the response type doesn't match the reply url purpose, but given deeplinks on mobile platforms I don't believe that's possible. |
#please-close |
yeah CORS issues on PKCE frustrating - probably need abandon Azure B2C. Any updates |
Hi @hpsin , are there any changes regarding the CORS support? We need it for de code grant flow because the implicit grant flow does not provide the 'groups' claim. |
Just came across this, is ADAL library also affected by this CORS limitation ? |
From what my tests showed, it is. |
One of our customers has a policy that disallows Implicit flow from being turned ON on any AD app. Following Microsoft documentation here (https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow) which seems to claim that the implementation follows the PKCE RFC we opted to proceed with it only to find out.
What would be best way for us to proceed? We are planning to off-load the PKCE token flow to a backend API that takes over the token retrieval and returns to front end. We are investigating security implication. Any pointers from the Microsoft team would be helpful. Even in terms of timelines for full PKCE support. |
Hello, i'm trying to get an Authorization Code through a JQuery Call; the users will be authenticated through SSO and so no interaction; but this error response is returned from the Authorization URL: Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://login.microsoftonline.com/45392360-6e37-4be7-acfb-4c…c1a-d748-434a-9345-3ca9f53f11e4/.default&state=1587456553230. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). The reason is obvious, no Access-Control-Allow-Origin is present on the Response so the browser discards it; Is there a way to configure proper CORS for that URL on the Azure Active Directory Application or the only way to get an authorization code is using full browser redirect / pop-up ? Thank you. |
Thank you for this documentation. I appreciate the effort to maintain thorough documentation.
The authorization code flow does not work for an SPA, due to https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token not providing CORS headers.
Also client_secret needs to be provided, even though that is strange, due to it being required in frontend code and therefore being insecure.
Since Authorization Code without client secret and with PKCE is the recommended flow for SPAs, we would like to use this. The problem described is however a blocker for us.
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
The text was updated successfully, but these errors were encountered: