Subject: [OAUTH-WG] sites with wildcard

From: "Manger, James H" <[email-masked]>
Date: Tue, 11 May 2010 00:32:38 +1000

There are various ways to indicate where a token can be used (when an authorization server issues a token to a client app).

A. List of URI prefixes

B. List of scheme://host[:port] tuples

C. List of domain names

D. Any of the above lists with a wildcard to include all sub-domains, eg “sites”:[“https://*.example.com”]

E. Regular expression

I have been suggesting (B).

HTTP Digest uses (A). (A) is a pretty good match to how Google uses scope values.

(C) is a little simpler; but unacceptable because we should distinguish HTTP and HTTPS.

A regular expression (E) could do the job.

(D) can cover some virtual hosting situations where almost arbitrary numbers of sub-domains are continually created (eg per-user sub-domains). Eran asked for wildcards.

If a wildcard is allowed I suggest only allowing a single “*.” prefix to the domain name. Its presence would mean all sub-domains (but not the parent domain, which can be specified separately if needed). Probably easiest to include sub-sub-domains etc.

I could live with A, B, D, or E (just not C, and not nothing).

Suggested text for B+D for the Access Token Response section:

  sites

    OPTIONAL. An array of strings indicating the sites where the token can be used.

The optional “sites” field indicates where the issued token can be used. Its value is an array of strings, where each string obeys the “site” production. If the “sites” field is absent it MUST be treated as though the field was present with a single string consisting of the scheme, host, and port of the request that returned the token.

  site := scheme “://” [wildcard “.”] host [“:” port]

  wildcard := “*”

The token MUST NOT be used with a request to a URI unless the URI matches at least one string in the “sites” value. A token SHOULD be used pre-emptively when the URI does match. A URI matches a string if the following conditions are all met:

1. The scheme of the URI and string are equal, ignoring case.

2. The port number of the URI and string are numerically equal, using the default port number for a scheme if no port is specified (eg 443 for https).

3. The host of the URI and string are equal, ignoring case, and (if the wildcard is present) ignoring one or more leading domain labels of the URI host.

Example:

  “sites”: [“https://api.example.com”, “https://*.data.example.com”]

The following URIs match (so the token should be used):

  https://api.example.com:443/xyz?q=1

  HTTPS://WWW.IMG.DATA.EXAMPLE.COM/786856.jpg

The following URIs do NOT match (so the token must not be used):

  http://api.example.com/index.html  (wrong scheme)

  https://data.example.com/4254.json  (host not a sub-domain)

--

James Manger

---

From: Brian Eaton <[email-masked]>
Date: Mon, 10 May 2010 16:11:08 -0700

On Mon, May 10, 2010 at 7:32 AM, Manger, James H
<[email-masked]> wrote:
> HTTP Digest uses (A) [A. List of URI prefixes]. (A) is a pretty good match to how Google uses scope
> values.

It's not, actually.  Our scopes are sometimes URI prefixes, and
sometimes are not.  The reality is complicated, and to be honest is
poorly documented.  We're working on it.

As I've said in a few other e-mail threads, I think it would be a
serious mistake to publish a standard that doesn't reflect things that
are already deployed in the wild and are well-understood.

If people want to see systems that automatically determines scopes and
reuses tokens, I think they should go and build those systems.  Then
come back to the community with explanations of what they did, and why
other people should adopt it.

Cheers,
Brian

---

From: Yaron Goland <[email-masked]>
Date: Mon, 10 May 2010 23:45:14 +0000

I don’t understand the scenario that requires this feature. When does someone ask for a token without knowing where it is going?

From: [email-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Monday, May 10, 2010 7:33 AM
To: OAuth WG ([email-masked])
Subject: [OAUTH-WG] sites with wildcard

A. List of URI prefixes

  sites

Example:

--
James Manger

---

From: Yaron Goland <[email-masked]>
Date: Mon, 10 May 2010 23:52:08 +0000

+1

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian Eaton
> Sent: Monday, May 10, 2010 4:11 PM
> To: Manger, James H
> Cc: OAuth WG ([email-masked])
> Subject: Re: [OAUTH-WG] sites with wildcard
> 
> > HTTP Digest uses (A) [A. List of URI prefixes]. (A) is a pretty good
> > match to how Google uses scope values.
> 
> It's not, actually.  Our scopes are sometimes URI prefixes, and sometimes are
> not.  The reality is complicated, and to be honest is poorly documented.
> We're working on it.
> 
> As I've said in a few other e-mail threads, I think it would be a serious mistake
> to publish a standard that doesn't reflect things that are already deployed in
> the wild and are well-understood.
> 
> reuses tokens, I think they should go and build those systems.  Then come
> back to the community with explanations of what they did, and why other
> people should adopt it.
> 
> Cheers,
> Brian
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 11 May 2010 10:31:22 +1000

Yaron,

Example:

A client app gets a token to make an API call to a protected resource that returns an Atom feed.

The feed contains lots of entries, with links to photos, style sheets, and scripts.

The client app gets the photos.

Should it send the token when getting the photos?

On service A the Atom feed and the photos are all served from the same HTTPS host, with the same protection, so the token must be sent.

On service B the photos are hosted on a separate outsourced content distribution network. The photos are protected by using long unguessable URIs (the URIs are effectively “capabilities” to read the photos). The token does not need to be sent.

On service C the photos are any images from anywhere on the Internet that the user has chosen to link to. The Atom collection is protected, but not the photos. The token absolutely must not be sent when getting the photos.

A client app needs to know whether the service it is accessing is like A, B, or C. It needs to know for redirects, for links in HTTP headers, for links to images, for any other sort of link that is can derive from the response.

Some services might be completely walled gardens so the client can assume they are like A.

Some services might explicitly state in their documentation: which links and redirects are always guaranteed to be other API calls (send the token); which will always be to other security contexts (don’t send the token); and which might be either (don’t send the token, see if you get a 401/403, guess, send the token).

In general, the web is about following links. Clients need to know when following a link crosses a security boundary. Cookies provide this; Basic provides this; Digest provides this; OAuth needs this too.

--

James Manger

---

From: David Recordon <[email-masked]>
Date: Mon, 10 May 2010 18:34:05 -0700

Hey James,
I guess the way that we solved this was having the Protected Resource
include the access token in links as applicable. We don't do cross
site access tokens and I'd hate to see us standardize this more
complex use case without real world deployment experience.

Do you have an implementation with this problem that we can look at?

Thanks,
--David

On Mon, May 10, 2010 at 5:31 PM, Manger, James H
<[email-masked]> wrote:
> Yaron,
>
>
>
>> I don’t understand the scenario that requires this feature. When does
>> someone ask for a token without knowing where it is going?
>
>
>
> Example:
>
> On service A the Atom feed and the photos are all served from the same HTTPS
> host, with the same protection, so the token must be sent.
>
>
>
> On service B the photos are hosted on a separate outsourced content
> distribution network. The photos are protected by using long unguessable
> URIs (the URIs are effectively “capabilities” to read the photos). The token
> does not need to be sent.
>
>
>
> On service C the photos are any images from anywhere on the Internet that
> the user has chosen to link to. The Atom collection is protected, but not
> the photos. The token absolutely must not be sent when getting the photos.
>
>
>
>
>
> A client app needs to know whether the service it is accessing is like A, B,
> or C. It needs to know for redirects, for links in HTTP headers, for links
> to images, for any other sort of link that is can derive from the response.
>
>
>
> Some services might explicitly state in their documentation: which links and
> redirects are always guaranteed to be other API calls (send the token);
> which will always be to other security contexts (don’t send the token); and
> which might be either (don’t send the token, see if you get a 401/403,
> guess, send the token).
>
>
>
> In general, the web is about following links. Clients need to know when
> following a link crosses a security boundary. Cookies provide this; Basic
> provides this; Digest provides this; OAuth needs this too.
>
>
>
>
>
> --
>
> James Manger
>

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 11 May 2010 12:10:58 +1000

Hi David,

> include the access token in links as applicable.

Yes, I noticed Facebook did this in some actual responses (though I don't think I saw it documented).
I don't personally think it is a great architectural choice, but I guess it works for Facebook today.
I hope that isn’t the only approach feasible with OAuth.

Including tokens in links does not work if you want to use the Authorization HTTP header -- which offers some security benefits, and is part of OAuth.
It doesn't play that nicely with other aspects of the web architecture (such as caching, etags, conditional requests, bookmarks...) as all the URIs change for each client/user/refresh. The server also has to dynamically generate each page for each token.
It puts secrets in places where they might not be expected. Do Facebook apps know that exposing the content of a protected resource or exposing a link it contains also exposes their secret token? That doesn't happen with other authentication schemes. Tokens in URIs will end up in more logs and search engine indexes etc.

> We don't do cross site access tokens

Are you sure you will not in the future (perhaps after a merger or acquisition)?

> and I'd hate to see us standardize this more complex use case

Its not very complex, particularly if the default value for "sites" was the site returning the token. Facebook wouldn't have to do anything! Even Facebook-specific apps could ignore any "sites" field and just hard-wired a rule to use a Facebook token on initial requests to https://graph.facebook.com URIs and that's all (assuming Facebook says that is how their API is designed to work).

> Do you have an implementation with this problem that we can look at?

The whole Internet is a web of links across security boundaries.
I don't have a specific OAuth implementation to champion this issue.

--
James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 11 May 2010 12:17:58 +1000

Brian,

OAuth bearer tokens are to a large degree glorified cookies. Cookies have been massively deployed in the wild with their own variety of a "sites" parameter ("domain", "path" and "secure" parameters).

The biggest different between cookies and OAuth tokens today is that a client app needs a huge dollop of service-specific knowledge to use OAuth.

I'd argue that the cookie experience counts as determining what a bearer token system needs to work at Internet scale.

P.S. I have a hazy memory that Google did use redirects with an OAuth 1 API that caused some clients to break. I think some re-signed requests, and others didn't. That might be a case where a "sites" parameter would have made the right approach obvious (unless it was just an escaping issue). Anyone have a better memory?

-- 
James Manger

-----Original Message-----
From: Brian Eaton [mailto:[email-masked]] 
Sent: Tuesday, 11 May 2010 9:11 AM
To: Manger, James H
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] sites with wildcard

...

Cheers,
Brian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 10 May 2010 19:46:21 -0700

I strongly agree.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Monday, May 10, 2010 5:31 PM
To: Yaron Goland; OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] sites with wildcard

Yaron,

Example:

--
James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 10 May 2010 20:07:01 -0700

Redirections are a bad example when used with an access token in the query parameter...

EHL

> Of David Recordon
> Sent: Monday, May 10, 2010 6:34 PM
> To: Manger, James H
> include the access token in links as applicable. We don't do cross site access
> tokens and I'd hate to see us standardize this more complex use case
> without real world deployment experience.
> 
> >> I don't understand the scenario that requires this feature. When does
> > On service A the Atom feed and the photos are all served from the same
> > HTTPS host, with the same protection, so the token must be sent.
> >
> >
> >
> > distribution network. The photos are protected by using long
> > unguessable URIs (the URIs are effectively "capabilities" to read the
> > photos). The token does not need to be sent.
> >
> >
> >
> > On service C the photos are any images from anywhere on the Internet
> > that the user has chosen to link to. The Atom collection is protected,
> > but not the photos. The token absolutely must not be sent when getting
> the photos.
> >
> >
> >
> >
> >
> > A client app needs to know whether the service it is accessing is like
> > A, B, or C. It needs to know for redirects, for links in HTTP headers,
> > for links to images, for any other sort of link that is can derive from the
> response.
> >
> >
> >
> > Some services might explicitly state in their documentation: which
> > links and redirects are always guaranteed to be other API calls (send
> > the token); which will always be to other security contexts (don't
> > send the token); and which might be either (don't send the token, see
> > if you get a 401/403, guess, send the token).
> >
> >
> >
> > In general, the web is about following links. Clients need to know
> > when following a link crosses a security boundary. Cookies provide
> > this; Basic provides this; Digest provides this; OAuth needs this too.
> >
> >
> >
> >
> >
> > --
> >
> > James Manger
> >

---

From: Brian Eaton <[email-masked]>
Date: Tue, 11 May 2010 09:18:08 -0700

> provides this; Digest provides this; OAuth needs this too.

Notably absent from the list of protocols that need this:
- AuthSub
- ClientLogin
- BBAuth
- FBAuth
- AOL OpenAuth
- OAuth 1.0

Cheers,
Brian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 11 May 2010 10:49:01 -0700

This is completely meaningless.

This list is all vendors specific (including OAuth 1.0 which lacks any form of discovery) which means libraries can easily hard-code the sites allowed into their library. Also, because there really isn't any authentication challenge involved, there is no issue with unfamiliar servers.

On the other hand, browsers encounter Cookie and Basic authentication requests all the time, and always with unfamiliar servers. That's the relevant example.

EHL

> Sent: Tuesday, May 11, 2010 9:18 AM
> To: Manger, James H

---

From: Brian Eaton <[email-masked]>
Date: Tue, 11 May 2010 10:52:30 -0700

> On the other hand, browsers encounter Cookie and Basic authentication requests all the time, and always with unfamiliar servers. That's the relevant example.

Cookies and basic auth are largely irrelevant, because OAuth 2 doesn't
need to replace cookies and basic auth.  Cookies and basic auth work
*just fine* in web browsers today.  Every vendor participating in this
discussion uses cookies, so I'd say that we have all the
standardization we need in that space.

OAuth 2 does need to replace all the vendor specific delegation
protocols, though.

Cheers,
Brian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 11 May 2010 11:03:17 -0700

That's a pretty limited view on what OAuth 2.0 is for.

EHL

> Sent: Tuesday, May 11, 2010 10:53 AM
> To: Eran Hammer-Lahav
> Cc: Manger, James H; OAuth WG ([email-masked])
> > This list is all vendors specific (including OAuth 1.0 which lacks any form of
> discovery) which means libraries can easily hard-code the sites allowed into
> their library. Also, because there really isn't any authentication challenge
> involved, there is no issue with unfamiliar servers.
> >
> > On the other hand, browsers encounter Cookie and Basic authentication
> requests all the time, and always with unfamiliar servers. That's the relevant
> example.
> 
> Cookies and basic auth are largely irrelevant, because OAuth 2 doesn't need
> to replace cookies and basic auth.  Cookies and basic auth work *just fine* in
> web browsers today.  Every vendor participating in this discussion uses
> cookies, so I'd say that we have all the standardization we need in that space.
> 
> OAuth 2 does need to replace all the vendor specific delegation protocols,
> though.
> 
> Cheers,
> Brian

---

From: Brian Eaton <[email-masked]>
Date: Tue, 11 May 2010 11:38:51 -0700

> That's a pretty limited view on what OAuth 2.0 is for.

It it what has brought a large community into this mailing list.

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 11 May 2010 14:11:38 -0700

> Should it send the token when getting the photos?

I would say definitely not. If the client gets back a 403 with
discovery info that points to the same authz server and approved
scopes, only then could the client re-try with a token.

Would that work?

Marius

---

From: Yaron Goland <[email-masked]>
Date: Tue, 11 May 2010 23:09:43 +0000

Limited views on what a protocol is far tend to produce protocols that are actually interoperable. We should strive to do as little as possible in the standard and make sure we do a great job leaving the door open to later extensions.

> Sent: Tuesday, May 11, 2010 11:39 AM
> To: Eran Hammer-Lahav

---

From: Yaron Goland <[email-masked]>
Date: Tue, 11 May 2010 23:28:51 +0000

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.

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.

                                Just a thought,

                                                Yaron

From: Manger, James H [mailto:[email-masked]]
Sent: Monday, May 10, 2010 5:31 PM
To: Yaron Goland; OAuth WG ([email-masked])
Subject: RE: sites with wildcard

Yaron,

Example:

--
James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 11 May 2010 16:36:01 -0700

> Of Yaron Goland
> Sent: Tuesday, May 11, 2010 4:29 PM
> To: Manger, James H; OAuth WG ([email-masked])
> 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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 11 May 2010 16:42:45 -0700

We should strive to do as much as rough consensus allows. The way we decide what's in scope is by discussing it until we reach a mature proposal. Objections must always come with a technical argument why the proposal is bad.

All specs include features that are a little bit experimental (in OAuth 1.0 it was Google's demand for RSA support). There is nothing wrong with that as long as the core (and required) parts are well specified.

People are here for many reasons.

EHL

> From: Yaron Goland [mailto:[email-masked]]
> Sent: Tuesday, May 11, 2010 4:10 PM
> To: Brian Eaton; Eran Hammer-Lahav
> Subject: RE: [OAUTH-WG] sites with wildcard
> 
> Limited views on what a protocol is far tend to produce protocols that are
> actually interoperable. We should strive to do as little as possible in the
> standard and make sure we do a great job leaving the door open to later
> extensions.
>

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 12 May 2010 10:37:28 +1000

Marius,

> Would that work?

No. That would be totally insecure.

Any site can return a 403 and list, say, Google as its authz server so any site (good or bad) could get a client to reveal its Google token.

--
James Manger

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 12 May 2010 09:27:36 -0700

> Any site can return a 403 and list, say, Google as its authz server so any site (good or bad) could get a client to reveal its Google token.

Good point.

Thanks for clarifying all my questions.

Marius

---

From: Yaron Goland <[email-masked]>
Date: Thu, 13 May 2010 20:52:07 +0000

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

> From: Eran Hammer-Lahav [mailto:[email-masked]]
> Sent: Tuesday, May 11, 2010 4:36 PM
> To: Yaron Goland; Manger, James H; OAuth WG ([email-masked])
> > 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

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 17 May 2010 00:09:09 +1000

Below is text about the "sites" field in spec-ready detail to make it easier for the editor.
There hasn't been unanimous support for this field amongst the long discussions. However, my feeling is that most have recognised that it is needed.

[for 3.3.2.1. Access Token Response]

[add to the list of common parameters]

  sites
    OPTIONAL. Indicates the sites where the token can be used.

[add below the list of common parameters]

The "sites" field indicates where the issued token can be used. Its value is an array of strings, where each string obeys the <site> production. If the "sites" field is absent it MUST be treated as though the field was present with a single string consisting of the scheme, host, and port of the site that issued the token.
 
  site     = scheme "://" [wildcard] host [":" port]
    ; scheme, host, and port are defined in [RFC3986]
  wildcard = "*."

The token MUST NOT be used with a request to a URI unless the URI matches at least one string in the “sites” value. A token SHOULD be used pre-emptively when the URI does match. Any string in the "sites" value that does not obey the <site> production MUST be ignored. A URI matches a string if the following conditions are all met:
1. The scheme of the URI and string are equal, ignoring case.
2. The port number of the URI and string are numerically equal, using the default port number for a scheme if no port is specified (eg 443 for https).
3. The wildcard is absent and the host of the URI and string are equal, ignoring case; or the wildcard is present and a "." followed by the host of the string is a suffix of the host of the URI, ignoring case.

The following URIs match the example below (so the token should be used):
  https://api.example.com:443/xyz?q=1
  HTTPS://WWW.IMG.DATA.EXAMPLE.COM/786856.jpg

The following URIs do NOT match the example below (so the token must not be used):
  http://api.example.com/index.html  (wrong scheme)
  https://data.example.com/4254.json  (host not a sub-domain)

[add the following line to the example HTTP response]

  "sites": ["https://api.example.com", "https://*.data.example.com"],

[may need to reference the ABNF RFC (instead of httpbis for ABNF?)]

   [RFC5234]  "Augmented BNF for Syntax Specifications: ABNF"

[end of spec text]

Potential issues:
* Internationalized domain names: the text above implies toASCII domain names appear in "sites" (by using <host> from RFC3986 URI, not <ihost> from RFC3987 IRI)
* <wildcard> doesn't make much sense if <host> is an IP addresses, but isn't harmful
* draft-abarth-origin offers more rigorous rules for scheme/host/port origins
* ignoring strings that don't match <site> provides some room for extensibility, while being fail-safe for earlier client apps

-- 
James Manger

---

From: Dick Hardt <[email-masked]>
Date: Sun, 16 May 2010 11:58:25 -0700

Looking over the previous threads, I don't think an important capability was
pointed out that we want to preserve:

The AS may NOT need or want to know where an access token is used. In other
words, the access token could be viewed as a claim that can presented to an
arbitrary resource to gain access.  This enables new resources to be
deployed without having to *register* them at the AS.

One way to deal with the security issues of a bearer token is to signing
with a private key belonging to the client which prevents reuse of the
access token by an unscrupulous  PR as the signed request will be bound to
that PR.

The proposal below does not preclude this capability as written as the sites
parameter is optional, so I am not suggesting a change, but am pointing out
the capability.

-- Dick

On Sun, May 16, 2010 at 7:09 AM, Manger, James H <
[email-masked]> wrote:

> There hasn't been unanimous support for this field amongst the long
> discussions. However, my feeling is that most have recognised that it is
> needed.
>
>
> The "sites" field indicates where the issued token can be used. Its value
> is an array of strings, where each string obeys the <site> production. If
> the "sites" field is absent it MUST be treated as though the field was
> present with a single string consisting of the scheme, host, and port of the
> site that issued the token.
>
> The token MUST NOT be used with a request to a URI unless the URI matches
> at least one string in the “sites” value. A token SHOULD be used
> pre-emptively when the URI does match. Any string in the "sites" value that
> does not obey the <site> production MUST be ignored. A URI matches a string
> if the following conditions are all met:
> 2. The port number of the URI and string are numerically equal, using the
> default port number for a scheme if no port is specified (eg 443 for https).
> 3. The wildcard is absent and the host of the URI and string are equal,
> ignoring case; or the wildcard is present and a "." followed by the host of
> the string is a suffix of the host of the URI, ignoring case.
>
> * Internationalized domain names: the text above implies toASCII domain
> names appear in "sites" (by using <host> from RFC3986 URI, not <ihost> from
> RFC3987 IRI)
> * ignoring strings that don't match <site> provides some room for
> extensibility, while being fail-safe for earlier client apps
>
> --
> James Manger
>

---

From: David Recordon <[email-masked]>
Date: Sun, 16 May 2010 12:17:05 -0700

Dick, that's a really good point! I'm glad you brought it up because I think
it got lost in the focus on this one use case.

James, thanks for writing this up!

I'm wondering if this could be first written and deployed as an extension
and we see if and how it gets used in the wild. Otherwise I think a strong
argument should be presented from a security perspective as to why it must
be in the core spec itself versus documented as a security consideration.

--David

On Sun, May 16, 2010 at 11:58 AM, Dick Hardt <[email-masked]> wrote:

> Looking over the previous threads, I don't think an important capability
> was pointed out that we want to preserve:
>
> The proposal below does not preclude this capability as written as the
> sites parameter is optional, so I am not suggesting a change, but am
> pointing out the capability.
>
> -- Dick
>
>

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 17 May 2010 11:22:55 +1000

Dick,

> One way to deal with the security issues of a bearer token is to signing with a private key belonging to the client which prevents reuse of the access token by an unscrupulous PR as the signed request will be bound to that PR.

This is no longer a bearer token. It is a token bound to a public key (eg like an X.509 certificate, or (more likely) a SAML assertion with <SubjectConfirmation>...holder-of-key</..>).

I can see that such non-bearer tokens don't necessarily need a "sites" field to ensure their security. "sites" is required to keep bearer tokens secure. Hence, the token response needs to tell the client a bit more about the nature of the token.

> The proposal below does not preclude this capability as written as the sites parameter is optional, so I am not suggesting a change, but am pointing out the capability.

The "sites" parameter DOES preclude this capability. It says "OPTIONAL", but this actually means "a default value is defined". The default is that the token can only be used at the site that issued it, which is not what you want.

Suggested solution: define a special string "*" that, when present in the "sites" array, means the token can be used anywhere without compromising its security (eg "sites":["*"]). 

Alternative 2: set "sites":null when a token can be used anywhere.
Alternative 3: don't define a default; absence of "sites" means the token can be used anywhere; "sites" is required even if the token can only be used at the site that issued it (eg Facebook needs to add "sites":["https://graph.facebook.com"]). This alternative is not quite so fail-safe (forgetting "sites" is insecure).

--
James Manger

From: Dick Hardt [mailto:[email-masked]] 
Sent: Monday, 17 May 2010 4:58 AM
To: Manger, James H
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Spec text for "sites" field

Looking over the previous threads, I don't think an important capability was pointed out that we want to preserve:

The AS may NOT need or want to know where an access token is used. In other words, the access token could be viewed as a claim that can presented to an arbitrary resource to gain access.  This enables new resources to be deployed without having to *register* them at the AS.

One way to deal with the security issues of a bearer token is to signing with a private key belonging to the client which prevents reuse of the access token by an unscrupulous  PR as the signed request will be bound to that PR.

The proposal below does not preclude this capability as written as the sites parameter is optional, so I am not suggesting a change, but am pointing out the capability.

-- Dick

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 17 May 2010 13:56:05 +1000

David,

> I think a strong argument should be presented from a security perspective as to why it ["sites"] must be in the core spec itself versus documented as a security consideration.

1. Using redirects and links to points across the web is core behaviour for many web clients and servers.
2. Bearer tokens are a core feature of OAuth2.
3. Combining 1 & 2 is only safe when a client can recognize when a link goes beyond an API (beyond the security context a bearer token was intended for).
4a. Redirects and links themselves don't include metadata about whether or not they leave an API.
4b. Relying on per-service per-response per-link documentation to determine the boundaries of an API is really limiting (and is not provided in practise). It cripples interop between clients and servers.
4c. A "sites" value provides the necessary details about where it is unsafe to use a bearer token.

The web (it seems to me) is substantially built on clients being able to interop with servers even when the client has limited server-specific knowledge (eg web browsers are the ultimate client, browsing the web with almost no pre-configured knowledge about specific sites).
Such clients are core to the web; should be core to OAuth2; and require "sites".

--
James Manger