SSO seems to have assigned the wrong meaning to OAuth consumer keys
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical SSO provider |
Triaged
|
Medium
|
Unassigned |
Bug Description
This doesn't directly affect any projects I'm working on right now, but could become more serious if we ever want to roll out OAuth 2.0 authentication to protect any services.
The current SSO API seems to treat the consumer_key as an identifier for the user, when the OAuth 1.0 spec makes it pretty clear that it is intended to identify the application making requests. That is, if application "foo" can talk to service "bar", we'd expect all requests from "foo" to share a single consumer key, rather than one consumer key for each user of "foo".
For OAuth 1.0 requests this isn't too bad, since the consumer key is passed with every request. In OAuth 2 though, requests will generally only include the token:
http://
http://
So if a service wanted to implement OAuth 2 authentication against SSO tokens, it would need an API that could look up the token information without providing a consumer_key. The tokens would also need to be globally unique, rather than only being unique for a given user. The API would ideally provide user information in addition to the token and consumer information.
Services like Ubuntu One currently try to import all tokens associated with a user by listing tokens associated with a particular consumer key. It would probably need an equivalent API that took a user identifier instead.
summary: |
- SSO seems to have a assign the wrong meaning to OAuth consumer keys + SSO seems to have assigned the wrong meaning to OAuth consumer keys |
I should also add that the concept of a consumer_ key/client_ id as defined in the specification can still be useful: a service might want to restrict what a particular client can do, which at the moment we can only do by matching on the free text description field.