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 <p...@fb.com> To: "oauth@ietf.org" <oauth@ietf.org> Date: 07-06-11 11:57 AM Subject: [OAUTH-WG] Proposed OAuth Extensions Sent by: oauth-boun...@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@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
