Shane,
We have been working on openID Connect (formerly known as openID AB) for some
time.
If there are standard ways to do things in OAuth 2.0 that we can reuse then it
saves us from inventing custom extensions for openID Connect.
We have identified the need to request multiple tokens as one issue that we
would have to extend.
Certainly FaceBook is doing that now.
We have been working on a standard token/assertion format (JWT) that can be
signed and encrypted. That will be submitted as a separate spec.
Facebook has their own signature that they have been using for a while. I
don't know that we are going to get 100% convergence on token formats overnight.
>From PAPE it turns out that one of the things people found most useful was the
>max-auth-age request to force interactive authentications.
For SSO use we also need to be able to request a PAPE policy/ AuthnContext.
That may however be specific to Connect and less useful in general OAuth.
We want to invent as little as possible outside of OAuth as possible. However
we are mindful of OAuth deadlines so the Connect working group has been trying
to track the spec as much as possible without requesting changes.
I understand Paul's request for those features, and they would make life easier
for those of us working on SSO.
The details probably need more discussion, on types of tokens names etc.
Regards
John Bradley
> • From: Shane B Weeden <sweeden at au1.ibm.com>
> • To: Paul Tarjan <pt at fb.com>
> • Cc: "oauth at ietf.org" <oauth at ietf.org>
> • Date: Tue, 7 Jun 2011 13:16:03 +1000
> • In-reply-to: <CA12D2B2.1CB84%pt at fb.com>
> • References: <CA12D2B2.1CB84%pt at fb.com>
> Just an observation - some of this function seems to have direct parallels
> in OpenID.
> E.g.
> display=none sounds very much like checkid_immediate
> prompt=xxx seems like a direct correlation to the PAPE extension
>
>
> Could things like signed_request and nonce be considered part of a custom
> token format in a separate token spec rather than part of the core -
> provided the client can be token-type-aware?
>
>
>
>
> From: Paul Tarjan <pt at fb.com>
> To: "oauth at ietf.org" <oauth at ietf.org>
> Date: 07-06-11 11:57 AM
> Subject: [OAUTH-WG] Proposed OAuth Extensions
> Sent by: oauth-bounces at ietf.org
>
>
>
> Hi fellow OAuthers,
>
> As we discussed at the meeting there are a few extensions that we'd like
> to implement. To do this, we'd like the response_type to be extensible. We
> are proposing two new values. "none" and "signed_request token" (and
> "token signed_request" for symmetry). Or if you want to turn response_type
> into a space separated list, that would work too.
>
> I'm also including our other extension parameters so you can see what we
> are planning incase others need similar functionality.
>
>
> ---
> response_type=none
>
> If this is specified then no code nor token is passed to the redirect_uri.
> This is very useful when the authentication will be done via other means
> (like the display=none parameter, or Facebook's canvas iframe).
>
> Example:
>
> http://www.facebook.com/dialog/OAuth
> ?
> client_id=150629244948164&
> redirect_uri=
> http://apps.facebook.com/ptarjan/&;
> ;
> response_type=none
>
> (shows user the permission dialog then redirects to)
>
>
> http://apps.facebook.com/ptarjan/
>
>
> (or if they click cancel)
>
>
> http://apps.facebook.com/ptarjan/
> ?
> error=access_denied&
> error_description=...&
> state=...
>
>
> ---
> response_type=signed_request
>
> This response type is used to tie the Javascript SDK to a server-side SDK.
> It is used in conjunction with response_type=token and display=none. It
> sends a "signed_request" along with the response, which is a signed blob
> that we expect the JS library to dump into a cookie for the server SDK to
> read and validate. The JS SDK will also look inside of it (without
> verifying the signature) to see the user's ID. That is safe because the JS
> SDK uses state and only handles responses it's expecting.
>
> The signed_request will contain:
>
> user_id (provider specific id string)
> issued_at (UNIXTIME)
> code (optional. OAuth code issued with redirect_uri set to ""
> since the server won't know which URL it was issued on)
> client_id (optional. Needed by Google for 4th party auth)
> audience (optional. Google's public key crypto)
> ... (other provider specific data)
>
> Example:
>
> http://www.facebook.com/dialog/OAuth
> ?
> client_id=150629244948164&
> redirect_uri=
> https://s-static.ak.fbcdn.net/connect/xd_proxy.php#&;
> ;
> display=none&
> response_type=token signed_request
>
> 302s to
>
>
> https://s-static.ak.fbcdn.net/connect/xd_proxy.php#
>
> access_token=...&
> expires_in=...&
> signed_request=abcd...
>
> And the JS SDK then does
>
> setcookie("fbc_"+client_id, signed_request)
>
>
> ---
> display=none
>
> This means the user never will see a dialog and is meant to be opened in
> an iframe by javascript to asynchronously get an access_token or discover
> the user's state.
>
> Example:
>
> http://www.facebook.com/dialog/OAuth
> ?
> client_id=150629244948164&
> redirect_uri=
> https://example.com/&;
> ;
> display=none&
> response_type=token
>
> If the user is not logged into Facebook, this endpoint 302s to
>
>
> https://example.com/#
>
> error=unknown_user
>
> If the user is logged in but hasn't authorized this app, it 302s to
>
>
> https://example.com/#
>
> error=not_authorized
>
>
> If the user has authorized the app then it 302s to the normal OAuth output
>
>
> https://example.com/#
>
> access_token=...&
> expires_in=...
>
>
> ---
> prompt=
>
> A parameter that changes some things with the OAuth prompt. These can be
> specified as a space/comma separated string.
>
> prompt=login
>
> This forces the user to enter their password again.
>
> prompt=consent
>
> This always shows the "Do you allow this app" dialog, even if they
> consented before. Google will only issue long lived tokens when the user
> clicks something.
>
> prompt=secure
>
> The user must be verified by secure (https) cookies. This protects the app
> from firesheep attacks.
>
> prompt=select_account
>
> The user will be shown a dialog to select amongst their connected accounts
> (Google wants this for multiple connected accounts).
>
>
> ---
> nonce=
>
> If this parameter is specified, the nonce is encoded in the access_token,
> which is then accessible via a "Token Info Endpoint". This is paired with
> prompt=login to guarantee the user put in their password before they buy
> something expensive with their paypal account.
>
> It is limited to a 20 character opaque string, but we recommend base64url
> encoding a set of random bits.
>
> Example:
>
> http://www.facebook.com/dialog/OAuth
> ?
> client_id=150629244948164&
> redirect_uri=...
> nonce=some_string
> response_type=code
>
> Does exactly the same OAuth flow, except when they hit
>
> https//graph.facebook.com/access_token?access_token=...
>
> They get back json with a key "nonce" being the nonce encoded inside the
> Token.
>
> _______________________________________________
> OAuth mailing list
> OAuth at ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
