CORS and the OAuth 2 authorization code flow

Question

I have a back end application that is protected with the OAuth 2 authorization code flow. The front end (javascript in browser) hits an authorization endpoint on the back end, the back end redirects the browser to an authorization code server, the user authenticates and then the authorization server redirects the browser back to the back end with an authorization code which the back end redeems for a token to access some services.

The problem is that these redirects all happen in succession and CORS in the browser is preventing the exchange. What do the servers need to do as far as CORS to make this flow work?

browser                                 -> POST app.com/auth
307 auth.com/auth?redirect=app.com/auth <-
browser                                 -> POST auth.com/auth?redirect=app.com/auth (with authorization header)
307 app.com/auth?authcode=fubar         <-
browser                                 -> POST app.com/auth?authcode=fubar

Is roughly how it is supposed to go.

EDIT: Browser says

XMLHttpRequest cannot load http://app.com/autho. The request was redirected to 'http://autho.com/auth?response_type=code&redirect_uri=http://app.com/autho&state=639bfbe7-fd20-4c04-8feb-c9f60f4d55a9&client_id=0xdeadbeef', which is disallowed for cross-origin requests that require preflight.

EDIT2: So the redirect works fine without the Authorization header. Guess that data is going in the body for now.

Solution

The thing that seems incorrect to me here is that you're trying to use a redirection protocol flow from JavaScript.

Normally, your browser gets redirected to the authorization server and upon successful authentication, the browser is redirected back to the application with an auth-code or access token (depending on which flow is used).

In that case, you are not talking to the authorization server from JavaScript, so cross origin considerations do not come into play.

If you want to use OAuth2 from a JavaScript client, I suggest you look at the implicit grant, which is a redirection flow designed for untrusted clients like JavaScript applications.

Comments

[kag0]

Interesting, so if the redirecting and parameter passing are all done from HTML CORS would not come into play? I don't use implicit grant because it's not the javascript application which needs the token (that has been taken care of elsewhere), it's the backend application which needs the token to access other apps/services.

[kag0]

For implicit grant, those redirects would also not be followed by javascript correct?

[MvdD]

Right, same origin policy applies to script loaded from domain A making API calls to domain B. If your backend application is a trusted client, you can use the auth code grant, but still your browser would navigate to the authorization server to authenticate. Same goes for implicit grant.

[JBaczuk]

Implicit grant is no longer recommended. docs.microsoft.com/en-us/azure/active-directory/develop/…. I think the question is whether the authorization page has to be server-side-rendered.