Why would there be any use experience at all?
1. An OAuth client gets a refresh token in the context of http://example.com
2. While interacting with http://example.com the OAuth client sees a link to
http://foo.com and has reason to believe that foo.com is actually part of
example.com but isn't sure.
3. So the OAuth client goes to the token issuer it uses for http://example.com
and submits its refresh token along with a scope pointing at http://foo.com.
4. At this point either http://example.com returns an access token for
http://foo.com or it doesn't.
This approach doesn't require discovery, user interaction or a change to the
existing protocol.
Yaron
> -----Original Message-----
> From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
> Sent: Tuesday, May 11, 2010 4:36 PM
> To: Yaron Goland; Manger, James H; OAuth WG (oauth@ietf.org)
> Subject: RE: sites with wildcard
>
>
>
> > -----Original Message-----
> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> > Of Yaron Goland
> > Sent: Tuesday, May 11, 2010 4:29 PM
> > To: Manger, James H; OAuth WG (oauth@ietf.org)
> > Subject: Re: [OAUTH-WG] sites with wildcard
> >
> > Thanks for explaining, I now believe I understand the use case.
> >
> > But I would point out that this is really an unsolved problem in
> > general and if we are to tackle it we have to deal with real concerns
> > such as – what happens if in the time since the site list was provided
> > and when the token was used the list was changed? If an attacker now
> > controls a previously listed site then the attacker can just swallow
> > the bearer token and do bad things. So now we have to think about
> > expiration information on the site list or a revocation mechanism or some
> kind of negotiation.
>
> Tokens can be short lived - that's why we have refresh tokens. And if there is
> a chance of the sites list changing, the tokens should not be issued to
> overlap
> with such a change. But in general, this is really not a real concern in any
> production environment where people lose control over their domain names
> in such a timeframe.
>
> > One wonders if it wouldn’t be simpler for clients that are in doubt to
> > just make another token request to the original service’s token issuer
> > with a scope for the desired site. That works with the existing
> > protocol and mitigates the previous attack.
>
> That's a very bad user experience (having to grand access again for the same
> client), assuming there even is a user to bug about authorization.
>
> EHL
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
