Is CORS ever needed during any aspect of OAuth / OpenIDConnect Authentication?

Question

I'm looking at OpenIDConnect authentication and trying to determine if either "simple CORS" or "complex CORS" is ever leveraged during authentication or authorization.

Background

A Simple CORS (with no preflight) involves:

HTTP method of:

• GET
• POST
• HEAD

And a content type of

• multipart/form-data
• application/x-www-form-urlencoded
• text/plain

Will result in a server provided Access-Control-Allow-Origin in the response

Any other X-header or Method will result in a preflight OPTIONS request.

Question

• Does any form of OAuth leverage CORS in a manner that uses pre flight requests? (Info on OpenID Connect preferred, but any implementation of OAuth is interesting)

• Does any form of OAuth leverage CORS lacking the pre flight request?

• What configuration of CORS would cause a security vulnerability for an OAuth identity provider, or relying party/resource?

Answer 1

I'm not sure about OpenID, but for OAuth there is no CORS involved for the actual authentication part, though it may be required on the resource server depending on the type of client that is connecting.

In RFC 6749, which defines the OAuth 2 framework, there are four different methods defined for the application to gain authorization (here, client means the server that wants to access the data, resource owner and end user mean the person who's data it is, who grants access to it, and host means the entity that provides the authorization and API endpoints):

• Authorization code, which is used when the client is running a server. This is the most common method.
• Implicit, which is used when the application is running inside the user's browser.
• Resource owner password credentials, which is where the end user's username and password are used to authenticate with the server directly. There isn't an auth flow for this - the user just has to give the application their password.
• Client credentials, which is where the client has automatic access to the resources. There isn't an auth flow for this because it's automatic.

When using the authorization code method, a high level overview for the auth flow is that the client redirects the user to an authorization page on the host. When the end user grants access, they are redirected back to the client's site. On receiving the request, the client's server will make a request to the host to swap the temporary token for a permanent token, which they then use to make API request from their server.

With this method, all requests are made from the client's server to the host server, so there is no need for CORS. The only requests made in the end user's browser are the redirects, which aren't affected by CORS.

When using the implicit method, when the end user is redirected after granting access, the permanent code is retrieved from the URL by a (javascript) script running in the end user's browser on the client's website. This code is then used by javascript scripts running in their browser to access the API.

CORS needs to be used for the actual API endpoints with this method (if the requests would need CORS anyway - there's nothing special about it being authenticated using OAuth, so GET requests don't need CORS but DELETE requests do), because they are being accessed from within the user's browser. However, the authentication flow doesn't need CORS because, again, it is handled using redirects rather than cross-origin requests.