SSO seems to have assigned the wrong meaning to OAuth consumer keys

Bug #978719 reported by James Henstridge
6
This bug affects 1 person
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://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-18#section-2.1
http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01#section-3.1

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
Revision history for this message
James Henstridge (jamesh) wrote :

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.

Revision history for this message
Ricardo Kirkner (ricardokirkner) wrote :

The current API is frozen, and we need to completely redesign the next version of the API, so this will be handled when we come to that.

Changed in canonical-identity-provider:
status: New → Triaged
importance: Undecided → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.