Subject: [OAUTH-WG] Proposed OAuth Extensions

From: Paul Tarjan <[email-masked]>
Date: Tue, 7 Jun 2011 01:53:39 +0000

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.

---

From: Shane B Weeden <[email-masked]>
Date: Tue, 7 Jun 2011 13:16:03 +1000

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 <[email-masked]>
To:	"[email-masked]" <[email-masked]>
Date:	07-06-11 11:57 AM
Subject:	[OAUTH-WG] Proposed OAuth Extensions
Sent by:	[email-masked]

Hi fellow OAuthers,

---
response_type=none

Example:

---

Example:

302s to

And the JS SDK then does

---
display=none

Example:

https://example.com/#
  error=unknown_user

https://example.com/#
  error=not_authorized

https://example.com/#
  access_token=...&
  expires_in=...

---
prompt=

prompt=login

prompt=consent

prompt=secure

prompt=select_account

---
nonce=

Example:

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth