Web Gadget Profile Proposal

[Steve Gordon]

I’ve authored along with Matt Burdick a proposal for a client-side profile for obtaining access tokens. This proposal enables a flow that relies on a cross-origin browser communication channel to securely hand an access token to a client. The flow currently uses the HTML5 postMessage API in modern browsers but doesn’t define the flow in down-level ones. Feedback is appreciated.

 

Thanks,
Steve Gordon

Microsoft Corporation

[Brian Eaton]

Hey Steve -

On Tue, Nov 24, 2009 at 12:45 PM, Steve Gordon <str...@gmail.com> wrote:
> I’ve authored along with Matt Burdick a proposal for a client-side profile
> for obtaining access tokens. This proposal enables a flow that relies on a
> cross-origin browser communication channel to securely hand an access token
> to a client. The flow currently uses the HTML5 postMessage API in modern
> browsers but doesn’t define the flow in down-level ones. Feedback is
> appreciated.

Looks good. Just to make sure I've understood... the client is
identified by the scheme and domain of the callback URL. The path is
not used. There is no client secret. Do I have those details right?

Rather than using window.postMessage, I think we should use a relay
URL, e.g. http://www.example.com/callback#access_token=<token>

The main reason to prefer window.postMessage to a relay URL is that
window.postMessage is lower latency and higher bandwidth. We're not
passing large messages, so a relay URL should be sufficient, and is
compatible with down-level browsers.

Cheers,
Brian

[Steve Gordon]

> Looks good.  Just to make sure I've understood... the client is
> identified by the scheme and domain of the callback URL.  The path is
> not used.  There is no client secret.  Do I have those details right?

[SG]: Yes, that's correct.

>
> Rather than using window.postMessage, I think we should use a relay

> URL, e.g.http://www.example.com/callback#access_token=<token>

>
> The main reason to prefer window.postMessage to a relay URL is that
> window.postMessage is lower latency and higher bandwidth.  We're not
> passing large messages, so a relay URL should be sufficient, and is
> compatible with down-level browsers.
>

[SG]: There is an additional reason to prefer the postMessage API over
a URL fragment: the Client can ensure authenticity that the message
was in fact sent by the resource provider. i.e.: anyone can pass an
access token back to this callback URL in an unverifiable fashion.
However, as I stated in a private reply to this proposal, if you are
comfortable with clients getting potentially bogus access tokens, you
can instead rely on subsequent calls to the resource provider to
ensure the integrity of the access tokens that they receive. This
simplification may actually be acceptable.

> Cheers,
> Brian

[Brian Eaton]

On Tue, Nov 24, 2009 at 6:29 PM, Steve Gordon <str...@gmail.com> wrote:
> [SG]: There is an additional reason to prefer the postMessage API over
> a URL fragment: the Client can ensure authenticity that the message
> was in fact sent by the resource provider. i.e.: anyone can pass an
> access token back to this callback URL in an unverifiable fashion.
> However, as I stated in a private reply to this proposal, if you are
> comfortable with clients getting potentially bogus access tokens, you
> can instead rely on subsequent calls to the resource provider to
> ensure the integrity of the access tokens that they receive. This
> simplification may actually be acceptable.

Note that this is true of the web app profile as well. Garden variety
XSRF protection using wrap_client_state can be used to prevent the
attack if it's a concern.

Cheers,
Brian

[Steve Gordon]

> Note that this is true of the web app profile as well.  Garden variety
> XSRF protection using wrap_client_state can be used to prevent the
> attack if it's a concern.
>

In the web app profile, a Client can be guaranteed that once it has
gotten an access token + refresh token it actually has a real one (due
to the TLS when communicating with the Access Token URL). In the
alternate flow that we're discussing here, the Client won't know until
it actually tries to use the Access Token to retrieve a resource.

You are absolutely correct that in both flows a secure client state
could be used to prevent XSRF, but in the former, the Access Token URL
process provides a guarantee irrespective of whether the Client
provides a secure client state. As I mentioned above, I don't think
that it's necessarily a bad thing that a Client could receive a
spoofed Access Token, however, the spec should call this out and be
clear on how this situation should be handled. Do you agree?

Thanks,
Steve

[Brian Eaton]

On Wed, Nov 25, 2009 at 7:07 AM, Steve Gordon <str...@gmail.com> wrote:
> You are absolutely correct that in both flows a secure client state
> could be used to prevent XSRF, but in the former, the Access Token URL
> process provides a guarantee irrespective of whether the Client
> provides a secure client state. As I mentioned above, I don't think
> that it's necessarily a bad thing that a Client could receive a
> spoofed Access Token, however, the spec should call this out and be
> clear on how this situation should be handled. Do you agree?

I think so... there seem to be two issues.

1) XSRF account linking.
Both web app and javascript flows are potentially vulnerable to
this, and the defense is the same. XSRF protect the callback URL.

2) Pure javascript handling of access tokens.
Client-side code can't tell whether a token is valid or not, and so
needs to be very sure to treat it as untrusted data.

Cheers,
Brian