search

socialcast / devise_oauth2_providable

Rails3 engine integrating OAuth2 authentication with Devise
MIT License
219 stars 102 forks source link

[Security problem] Auth code strategy doesn't verify client secret! #25

Closed BRMatt closed 12 years ago

BRMatt commented 12 years ago

According to the latest OAuth 2.0 spec the client_secret parameter is required when authenticating the client for access tokens.

Currently the secret is created in the model, but the authorization_code strategy only checks for the client_id and ignores the client_secret.

wireframe commented 12 years ago

you're referring to the client_credentials grant_type which is not currently supported with this gem.

per the spec: "Client credentials are used as an authorization grant typically when the client is acting on its own behalf (the client is also the resource owner), or is requesting access to protected resources based on an authorization previously arranged with the authorization server." http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-1.3.4

this is a very non-standard usecase IMO where each registered application is specific to one particular user. the much more standard scenerio is where a single third party application is distributed across any number of users. in this case, you're most likely to use either the authorization code, implicit, or Resource Owner Password Credentials grant_type. http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-1.3.3

if you have any more info, please feel free to reopen this issue.

BRMatt commented 12 years ago

Hmm, re-reading the spec again (section 2.3, not 1.3.4) it states that

Confidential clients are typically issued (or establish) a set of client credentials used for authenticating with the authorization server (e.g. password, public/private key pair).

e.g. if a client can protect its connection details then it should use some sort of secret token to authenticate to the server.

In fact, the integration specs reference the client_secret but I can't see anything in the strategies that reference it.

As an aside, the Github API uses Oauth 2.0 and requires the secret to be supplied when generating an access token

BRMatt commented 12 years ago

And it seems github doesn't let non-committers reopen issues

wireframe commented 12 years ago

thanks for the additional info. after re-reading the spec, i believe you're right. this is definitely a change from previous versions of the spec.

this appears to impact not only the authorization flow, but also the refresh_token grant type.