OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
Breno de Medeiros
breno at google.com
Tue Nov 18 04:00:52 UTC 2008
On Mon, Nov 17, 2008 at 7:53 PM, Manger, James H
<James.H.Manger at team.telstra.com> wrote:
> Dirk, Allen, Brian, etc
> How about sending an 'unauthorized request token' with the OpenID authentication request, instead of a scope or a consumer key?
> A Service Provider can choose to encode the consumer key or scope into the request token when issuing it if they need those details when interacting with the user.
That is how we started, but it adds a (probably unacceptable)
redundant server-to-server call for *every* authentication request. We
have decided to abandon this option after much debate. The request
token request is not needed for security reasons because (1) the
return_to URL is mandatory (hybrid only makes sense for web apps) and
(2) The OP/SP signs the response (unlike plain OAuth).
> From the OAuth perspective there would be minimal change to the protocol. Instead of redirecting the user to the authorization URL (after adding the token), the user is redirected to the OP URL (after adding the token). That makes it easier to be confident that the hybrid model does not introduce new security weaknesses.
> Ideally, an app would attempt to access a protected resource at an SP and get:
> * A 401 Unauthenticated response from the SP; with
> * A "WWW-Authenticate: OAuth" header; with
> * A parameter providing the authorization URL; and
> * Another parameter with the OP URL (when OpenID/OAuth hybrid was supported).
> If the app supports the hybrid mode, and the SP has indicated it supports the hybrid mode by including an OP URL in a 401 response, and the user's OpenID identifier resolves (via discovery) to the same OP, then the app can trigger the hybrid auth/authz action.
> James Manger
> 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