Skip to content
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

Closed
kyubisation opened this issue Sep 19, 2019 — with docs.microsoft.com · 19 comments
Closed

SPA usage does not work, due to CORS #39201

kyubisation opened this issue Sep 19, 2019 — with docs.microsoft.com · 19 comments

Comments

Copy link

kyubisation commented Sep 19, 2019

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.

@frankhu-2021
Copy link

@kyubisation Thanks for your feedback! We will investigate and update as appropriate.

Copy link

Romiko commented Sep 20, 2019

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!

@kyubisation
Copy link
Author

I can provide a minimal reproduction, if that helps in your investigation.

@rwike77
Copy link
Contributor

rwike77 commented Oct 14, 2019

@hpsin, mind taking a look at this one? Thanks.

@hpsin
Copy link
Contributor

hpsin commented Oct 14, 2019

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.

@hpsin
Copy link
Contributor

hpsin commented Oct 14, 2019

@kyubisation
Copy link
Author

That is a bit disappointing.
Nevertheless, thank you for answering the issue.

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.
However, we also had problems with the Implicit Flow, but I cannot provide details right now, since I'm on holidays and I do not have our example app available.
But since we are customers of AzureAD, we will go through official channels to report the problems, once I return to office.

@hpsin
Copy link
Contributor

hpsin commented Oct 14, 2019

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!

@kyubisation
Copy link
Author

Thank you for the heads-up.
I will try to do that next week.
Have a nice week! 😃

@kyubisation
Copy link
Author

@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.
Thank you very much for your offer to help/support, I really appreciate it.

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 😃

@hpsin
Copy link
Contributor

hpsin commented Oct 21, 2019

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.

@hpsin
Copy link
Contributor

hpsin commented Oct 21, 2019

#please-close

Copy link

yeah CORS issues on PKCE frustrating - probably need abandon Azure B2C. Any updates

@andreifloricel
Copy link

andreifloricel commented Mar 2, 2020

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.
According to this comment the CORS support should be in progress: AzureAD/microsoft-authentication-library-for-js#1000 (comment)

@hpsin
Copy link
Contributor

hpsin commented Mar 2, 2020 via email

@beowulf79
Copy link

Just came across this, is ADAL library also affected by this CORS limitation ?

@BernhardRode
Copy link

From what my tests showed, it is.

@omkarkhair
Copy link
Contributor

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.

  1. It requires a client secret for Token retrieval
  2. Does not support CORS (thankfully? because client secret?)

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.

@beowulf79
Copy link

beowulf79 commented Apr 21, 2020

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).
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

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests