Confusion around password grant

[ekosz]

The documentation around the password grant currently states:

To obtain a token you should POST to /oauth/token. You should include your client credentials in the Authorization header ("Basic " + client_id:client_secret base64'd)

But isn't that a security concern? Lets say I embed the base64 of the client_id and client_secret in my JS, couldn't anyone then unbase64 it and get my client_secret? I would have thought that you would only need to send the client_id for identification and the username + password for verification.

According to blogs like this one you're only ever meant send the client_id.

[oliverkane]

I'm a recent consumer of this node module. I too had the same question.
+1

[visvk]

The blog uses information from an old draft http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-4.3 from May 2011. But this Internet-Draft has expired on November 20, 2011.

So, no, you cannot use only client_id for password_grant

[mickadoo]

@visvk I'm no expert on OAuth, out of curiosity where is the requirement for client_secret based on?

Looking at https://tools.ietf.org/html/rfc6749#section-4.3 it seems like neither client_id or client_secret are required.

[mickadoo]

I'll just add my workaround for anyone who might be interested

app.all('/oauth/token', function (req, res) {

    req.body.client_id = '<clientID>';
    req.body.client_secret = '<clientSecret>';

    return result = app.oauth.grant()(req, res, function(response){
        res.statusCode = response.code;
        res.send(response);
    });
});

[abalmos]

@visvk @mickadoo I believe the spec only requires clients to authenticate if they have client credentials:

...
   The authorization server MUST:

   o  require client authentication for confidential clients or for any
      client that was issued client credentials (or with other
      authentication requirements)
...

@ekosz I agree it is a security concern for public clients but not for confidential ones. Although I admit the main use cases for password grants are probably with public clients.

It seems node-oauth2-server should allow password grants for unauthenticated public clients and require authentication for confidential clients.

[visvk]

@abalmos you're right, but i saw that ekosz had client credentials issued, so by RFC he must use client authentication (client_id + client_secret). In my opinion ekosz is right too, that client credentials should not be used in public client (JS application).

... The authorization server should take special care when
   enabling this grant type and only allow it when other flows are not
   viable.

I think the auth server and client should minimize use of this granttype and utilize other grant types whenever possible.

I only quote from RFC. I'm no expert in OAuth 2.

[dkushner]

I am also curious about this, can we get @maxtruxa to confirm this? It appears that currently the password grant (which I understand to be the resource owner password credentials grant outlined in the OAuth 2.0 spec, requires that a client secret be submitted but isn't the purpose of this flow to allow for trusted hosts to submit user credentials without the redirect?

For my application, I have a deployed OAuth 2.0 authentication server and an SPA served as static content from an nginx deployment so that they can be developed and redeployed in parallel. I want to authenticate users from my SPA without the need to have an active backend that exists only to proxy my OAuth requests.

[maxtruxa]

To reiterate: Yes, the RFC requires clients to send the client_secret when using the password grant.

This requirement exists probably because the typical usage of OAuth is one where you don't expose username and/or password to the (often third-party) client. To prevent arbitrary clients from using the password grant you must ensure that the client is in fact allowed to use the password grant. You can't assume the client's identity by just looking at the client_id since it's public, so you need the public client_id and the private client_secret. The client_secret must not be exposed, so the conclusion is that only confidential clients can use the password grant.

If you need this functionality anyways, you can disable client authentication for selected grants through the requireClientAuthentication server option.

new OAuth2Server({
  // ...
  requireClientAuthentication: {password: false} // defaults to true for all grants
});

Possible keys for the object include all supported values for the token request's grant_type field (authorization_code, client_credentials, password and refresh_token).

[maxtruxa]

[...] but isn't the purpose of this flow to allow for trusted hosts to submit user credentials without the redirect?

Trusted hosts, yes. If you're sending the token request from a SPA you're not a trusted host though.

[theohdv]

@maxtruxa is this feature available in V3.0.0-b3.1 ? because I have this version on this module in my project but when I look into the code it is different than the github repository and there is no requireClientAuthentication in the code.

Workaround: Need to get master branch, last release does not include that feature. Maybe you should include it.

[dkushner]

Trusted hosts, yes. If you're sending the token request from a SPA you're not a trusted host though.

What about the implicit flow for OAuth 2.0? How would you suggest a native application authenticate with an OAuth 2.0 endpoint? The client secret cannot be securely held in the native application in the same way it cannot be held in an SPA. I ask this legitimately, as I'm apparently missing some secret to setting this up as clearly native applications and SPAs do make use of these flows.