davidrecordon / oauth-2.0 Goto Github PK

OpenSocial uses OAuth today to support server to server authentication via RSA public/private key pairs. I think that we could develop an authorization profile where a RSA key is used to retrieve an access token and then not have to support RSA as one of the signature mechanisms.

Currently there isn't a way to differentiate between when a client is expecting to handle UI from the authorization server versus when the user has already authorized the client and it is just requesting a new access token via JavaScript.

Also add more description around authorization server keeping track of when user has already approved the client.

From Marcel:
About the callback url in the Pure Client Profile, the current spec indicates that the server either redirects to the provided "oauth_callback" or uses the pre-registered one associated with the client application.

It seems necessary to additionally say that if an oauth_callback is provided the server MUST ensure that it has an identical host to the pre-registered callback url. This callback url is, from my vantage point, the only mechanism in the Pure Client Profile that affords even a modicum of security. Malicious attempts to get an access token using the Pure Client Profile are ultimately fruitless if you can't get the access token to be redirected back to you.

Unsophisticated server side code could be duped by a malicious callback that does something similar to SQL injection to trick the server side code into thinking a provided callback url is for the same domain when in fact it isn't, e.g. oauth_callback=http://evil.com?tricking_you=http://trusted.domain.com. Perhaps this too should be mentioned as a precaution to take.

Protected Resource is designed to not have the client identifier or secret.

Required parameter.