Add CORS feature to support AJAX use of password grant flow

[bertramn]

Hi there,

I am using the password grant flow via an ajax call where the requesting app is not running on the same domain as the OAuth server. Without CORS headers, the oauth password grant flow from a web client posting to the oauth server does not work. I did see some people just globally adding the CORS headers in the oauth server middleware or the fronting apache proxy, e.g.

app.use(function (req, res, next) {
    res.header('Access-Control-Allow-Origin', 'http://localhost:8100');
    res.header('Access-Control-Allow-Methods', 'GET,PUT,POST,DELETE');
    res.header('Access-Control-Allow-Headers', 'Content-Type');
    next();
});

Making CORS part of the client configuration will enable a per client configuration. The only thing that needs to be added is a configuration property to the client like client.addCorsHeader and for the actual header to be returned one could use the client.redirectUri parameter on the client. If the addCorsHeader property is enabled, simply strip off the path from the client redirectUri and return this in the Access-Control-Allow-Origin header with the response.

Et voila the OAuth server would now support CORS multiple different oauth clients that call from different domains using the password grant.

Does that work as a proposal and more importantly would this be a valid use case?

Cheers, Niels

Detailed use case:

OAuth server running on https://oauth.fancydomain.com
Client App running on https://myclient.com

Client App client is configured like:

{
    "clientId" : "id123",
    "clientSecret" : "some client secret",
   "addCorsHeader": true,
    "redirectUri" : "https://myclient.com/#/app/login"
}

OAuth server and Client App are from the same developer and the Client App only wants to post following to get an access token for use of some other backend API that is a protected resource server:

POST /oauth/token HTTP/1.1
Host: oauth.fancydomain.com
Cache-Control: no-cache
Content-Type: application/x-www-form-urlencoded

grant_type=password&username=somedude&password=secret&client_id=id123

The response the client is after will look something like this:

Remote Address: oauth.fancydomain.com
Request URL: https://oauth.fancydomain.com/oauth/token
Request Method: POST
Status Code: 200 OK
Access-Control-Allow-Headers: Content-Type
Access-Control-Allow-Methods: GET,PUT,POST,DELETE
Access-Control-Allow-Origin: https://myclient.com
...
Content-Type: application/json; charset=utf-8

{"token_type":"bearer","access_token":"a29fe185e2529917e7c778fb9b748a0912f030af","expires_in":2400}

[maennchen]

Have you thought about using the Implicit Flow instead of the Password Grant Type. This'll be a much cleaner implementation.

https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2#grant-type:-implicit

[bertramn]

Yes I did give implicit flow a thought but the line "it does not support refresh token" does not meet my requirements. I guess my thought stems more from the point of view that one would configure the allowable CORS origins and then only respond with a CORS ACAO header for the client requests send from that origin. I think almost all of the Auth SaaS solutions out there today do that sort of magic.

[maennchen]

You can configure your /authorize Endpoint that it does the redirect directly without comfirmimg if the user allready did once.
For CORS there are many plugins available which do just that.
Have a look at this project: https://www.npmjs.com/package/express-cors

[thomseddon]

I think CORS is probably out of scope of this module, as @maennchen say's you should be able to do this using existing plugins?

[bertramn]

If you run a multi tenanted OAuth server and you want to configure your client registration to only send CORS headers when they come from a specific URL location then you have no way of adding CORS headers during the Auth request as you never have access to the client registration, request and response objects in a single place.

Maybe another option would be to have a callback handler pattern in the OAuth server that will be consulted while processing the client requests. One could register any odd callbacks in there and when the callbacks are called, the OAuth server will pass in the client registration (the object it gets from the model) and the http request and response. This way one could write any type of plugins like some custom CORS handler with all the information about the client and request etc. in one place. Just a thought.

@maennchen, the authorize endpoint does not validate the resource owners credentials so no this flow is not what I want. The OAuth2 spec says "the authorization server authenticates the resource owner and obtains an authorization decision (by asking the resource owner or by establishing approval via other means)". Having said that, I find the spec itself quite confusing, it uses authentication and authorization interchangeably where nothing specific is ever said about the means to authenticate an actual resource owner.

[thomseddon]

General overrides has actually been spec'd here: https://github.com/thomseddon/node-oauth2-server/issues/115

[thomseddon]

Closing on no activity - please reopen if needed :)