OpenID/Oauth hybrid

Manger, James H James.H.Manger at team.telstra.com
Wed Nov 19 13:19:01 UTC 2008


How much special knowledge about the OP/SP is an app expected to have to use the OpenID/OAuth hybrid protocol?  [and some performance issues at the end]

A common case might be an app built to enhance one specific service. It is probably realistic to assume such an app is registered with the SP, and has hardwired knowledge about its OAuth URIs, scopes, signing modes etc.

Another case is an app that dynamically learns who a user's OP is (eg from OpenID discovery) and which SP the user uses for the service of interest (perhaps from the same OpenID discovery). The app notices that the OP and SP are the same (how?) and that they support the hybrid protocol (how?). This app understands OpenID, OAuth, hybrid, and the type of service of interest -- but has no special knowledge about this user's specific OP/SP.

The first case may cover many immediate pain points, particularly as OpenID and OAuth are in their infancy. However, a standard would be much more useful for the whole community and in the medium term if it supported the second case as well.

Even if the discovery aspects are not solved immediately, the hybrid protocol should not *preclude* apps without SP-specific knowledge once discovery mechanisms emerge.


The current hybrid draft adds openid.oauth.consumer and openid.oauth.scope fields to an OpenID request. The former forces the app to be pre-registered. The latter requires the app to know about the SP's specific scopes.

It seems possible that more parameters might be required in future: perhaps permissions (eg read/write), or lifetime (once-off, for 24 hours, forever).

All these parameters seem to tightly couple the app to the SP.

An alternative is to add one opaque handle to the OpenID request: a request token. To add a new scope, offer a new permission, support a new lifetime, etc an SP can offer a new URI for getting the new request tokens. As far as the app code is concerned it is just a URI, like any other URI. It doesn't necessarily need code that understands permissions, or scopes, or lifetimes etc.



Breno de Medeiros said the initial OAuth request for a token "adds a (probably unacceptable) redundant server-to-server call for *every* authentication request".

It may be better for performance to omit the request AFTER the redirect, instead of the request BEFORE the redirect.

OAuth involves:
1. get request token
2. redirect user to do authorization
3. swap request token for access token
4. do stuff

Step 3 was added to OAuth to support apps that could not launch/redirect-to a browser. Such apps need the user to manually type in a token, which needs to be short to be human-friendly. Step 3 allows a short token to be exchanged for a longer one that can encode lots of state so the service can operate in a stateless (scalable) manner.
Step 3 was kept for all OAuth apps (not just those that could not launch/redirect a browser) to keep the spec simple.

The hybrid protocol could save a request/response pair by dropping step 3 (or make it optional so apps that cannot launch/redirect-to a browser can use it).


The initial request for a request token (step 1) does not have to affect the user experience -- as it can be done in advance. An app could get request tokens in the background and cache them until one is needed for a hybrid auth/authz redirect.


Keeping step 1 but omitting step 3 means the access token needs to be returned in the authentication/authorization response. The request token secret can be used instead of getting a new access token secret.

The hybrid spec says [in section 3 Purpose]
  "For security reasons, the OAuth access token is not returned in the URL."
It is not clear what these security reasons are. I suspect they only apply because the hybrid protocol had dropped the token secret from step 1.


[It might not even be necessary to perform step 1 for *every* authentication request. If the returned token simply encodes the scope and/or consumer identity, then the service could set a Cache-Control header indicating that the token can be reused for, say, any authentication requests in the next day (I will have to think about any security implications).
Alternatively define a way for an app to get a batch of request tokens in one go.]



James Manger
James.H.Manger at team.telstra.com
Identity and security team — Chief Technology Office — Telstra


More information about the specs mailing list