OAuth 2 Autoconfiguration 401 Error for preflight request #1749

[rolaca11]

When sending requests from the browser with one of some combinations of method and headers, browsers tend to send a special preflight request, which is a kind of Cors request.

These requests are sent with the method OPTIONS, containing headers like Access-Control-Request-*.

An example

when using OAuth2 authentication, we send a POST request to /oauth/token, with HTTP's Basic authorization header. This kind of request is handled correctly by the autoconfiguration.

But when a browser sends a preflight request, it doesn't tend to send the Authorization header needed to access the given resource, because the configuration expects fullyAuthenticated clients on that, which causes the request to fail, resulting in a CORS error from the browser side.

My pull request allows all clients to access /oauth/token in case of an incoming OPTIONS request.
Based on my testing, the change solves the original problem, while not raising new ones.

Original issue: #1749

[pivotal-issuemaster]

@rolaca11 Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

[pivotal-issuemaster]

@rolaca11 Thank you for signing the Contributor License Agreement!

[rolaca11]

Could somebody explain, how can I fix (and prevent in the future) the issue on Travis-CI? I'm new to contributing to the Spring (or any other for the record) community

[rolaca11]

Upon further inspection, I realized, that there are other problems related to this subject.

In itself, this solution is enough, assuming the spring-webmvc version is 5.0.14.RELEASE, which is the case for the current master branch. With the latest spring-boot version, however the 5.1.9.RELEASE is packaged.

In this version, the way _CorsConfiguration_s are parsed changed a little, not defaulting to allow, but defaulting to a null value. Because of this, the DefaultCorsProcessor flags it as an "Invalid CORS Request", returning an error code of 403.

Since the latest spring-webmvc version used in this repo has not implemented some of the changes, the underlying issue cannot be solved.

Would it be appropriate to raise the spring.version in the parent pom XML and adjust the configuration accordingly? As I said, I'm new to this contribution thing, especially for this project, so I don't really know what I can/should or not do.

[jgrandja]

@rolaca11 I'd like to understand your use case in more detail. From what I can see, your flow has the browser calling the Token Endpoint directly? If this is the case, it is not recommended since the browser will receive the Access Token directly and may leak this through the browser (eg. internal storage cache). It is highly recommended to ensure the Access Token is stored in a secured environment, eg. on the server side.

Can you please describe your flow in detail along with the Authorization Grant being used.

I'm reluctant on adding OPTIONS for the Token Endpoint.

FYI, in case you are not aware, this project is in maintenance mode. Please see this post for more details.

Are you able to use Spring Security 5.2.0 OAuth support?

[rolaca11]

My flow I'm planning to use is something like this (with Angular on client-side):

I call the endpoint /oauth/token from the client, with username and password (which makes the grant_type password), which is then stored in the Angular service's variable, that can be injected into other services calling other endpoints.

I think that the only place where information can leak is when sending/receiving the credentials/tokens. My plan is to have the communication encrypted with https.

I don't really understand how this leak through internal storage works and how can the client know who it is without me sending the token. I feel like using the JSESSIONID cookie defeats the purpose of using OAuth authentication.

[jgrandja]

@rolaca11

I don't really understand how this leak through internal storage works...

If you do a google search using "is browser local storage secure" you will find plenty of articles. Here is one:
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/HTML5_Security_Cheat_Sheet.md#local-storage

with username and password (which makes the grant_type password), which is then stored in the Angular service's variable

Storing the user credentials is not recommended as this may leak too. The application should never store the user's credentials. When using the password, you should only use the credentials the one-time when obtaining the access token and then discard.

Also, since you're using the password grant, the client needs to authenticate with the provider when calling the token endpoint so you must be storing the client's credentials as well which is another issue.

As per spec, in Resource Owner Password Credentials Grant:

The resource owner password credentials grant type is suitable in
cases where the resource owner has a trust relationship with the
client, such as the device operating system or a highly privileged
application. The authorization server should take special care when
enabling this grant type and only allow it when other flows are not
viable.

I would strongly suggest that you use the authorization_code flow and have the client running server-side in a secure environment. Your Angular app only needs to have a session with the server. A typical pattern when a SPA needs access to multiple services is to go through an API Gateway. See the pattern for more details.

[jgrandja]

Closing due to lack of feedback.