Breno de Medeiros
breno at google.com
Wed Nov 19 18:03:01 UTC 2008
On Wed, Nov 19, 2008 at 5:19 AM, Manger, James H
<James.H.Manger at team.telstra.com> wrote:
> 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.
As I mentioned before, we purposefully let discovery outside of this
spec because there is a separate effort to standardize meta-data
discovery vs. XRD. If that effort is successful, I do not think any of
these issues are intractable.
> Even if the discovery aspects are not solved immediately, the hybrid protocol should not *preclude* apps without SP-specific knowledge once discovery mechanisms emerge.
It does not talk about discovery at all, exactly for that reason.
> 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.
The scopes are needed for the approval page to be rendered. The whole
thing is meaningless otherwise.
> 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.
I would say they tightly couple the request with the meaning of the
> 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.
You mean that the app has to understand all of the above, but will use
that knowledge during the discovery process, rather than
authorization. It needs to know what scope to ask. It needs to know
what permission to require. It does not need to know the lifetime the
OP enforces, but that just indicates that it has no place in the
> 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
> specs mailing list
> specs at openid.net
+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
More information about the specs