Subject: [OAUTH-WG] Indicating sites where a token is valid

From: "Manger, James H" <[email-masked]>
Date: Fri, 7 May 2010 09:57:32 +1000

The OAuth2 protocol does not indicate where a token can be used.

It needs to do so because if a client app sends a token to the wrong site it destroys the security.

I suggest another field in the JSON token response:

  "sites": ["https://api.example.com", "http://photo.example.com:8080"]

It would be a list of sites where the token can be used, specified by scheme://host[:port].

The default value for the “sites” field could be the token endpoint site (or the authorization endpoint site if a token endpoint isn’t used).

For instance, if Facebook’s new API uses https://graph.facebook.com for all resources, tokens, and authorizations it could omit the “sites” field.

P.S. I suggested this last month http://www.ietf.org/mail-archive/web/oauth/current/msg01920.html,  though I mixed in additional ideas for formats and media type that are probable best covered in their own treads.

--

James Manger

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 6 May 2010 17:11:13 -0700

Isn't this taken care of by the scope? I assume the requested scope is
associated with the issued access token.

It is up to the sites accepting the access tokens (the protected
resources) to verify and enforce the scope.

Marius

On Thu, May 6, 2010 at 4:57 PM, Manger, James H
<[email-masked]> wrote:
> The default value for the “sites” field could be the token endpoint site (or
> the authorization endpoint site if a token endpoint isn’t used).
>
> For instance, if Facebook’s new API uses https://graph.facebook.com for all
> resources, tokens, and authorizations it could omit the “sites” field.
>
>
>
>
>
> P.S. I suggested this last month
> http://www.ietf.org/mail-archive/web/oauth/current/msg01920.html,  though I
> mixed in additional ideas for formats and media type that are probable best
> covered in their own treads.
>
>
>
>
>
> --
>
> James Manger
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 7 May 2010 11:36:16 +1000

Marius

> Isn't this taken care of by the scope?

I don't think so. It looks similar to Google scopes (http://code.google.com/apis/gdata/faq.html#AuthScopes), but nothing like Facebook scopes (http://developers.facebook.com/docs/authentication/permissions).

> I assume the requested scope is associated with the issued access token.

I don't think we should require client apps to know all the sites a service uses for its resources (even those in a given scope) at the start of the flow. It kills interop for clients without much service-specific knowledge. It also constrains how services arrange (and re-arrange) their resources.

What should a client do when, on accessing a protected resource, it is redirected to another site?
Does it send the token to the new site?
Sometime sending the token will be dangerous — the other site shouldn't see these confidential tokens (eg https://api.example.com -307-> http://cdn.net/236423).
In other situations the token should be sent as the same service control both sites equally (eg https://api.example.com -307-> https://account.example.com).

As a concrete example, access the Facebook API such as https://graph.facebook.com/btaylor?metadata=1 and the response lists dozens of other URIs. Most of the URI are on the same site (https://graph.facebook.com) so presumably a client app can send the same token. Another URI is at a related site (http://www.facebook.com), but doesn't use TLS. Even if an app could tell this domain was "related" it probably shouldn't send the same token. If one of the listed connections was to an external site (eg "blog":"https://blog.example.org") I would assume the same token should NOT be sent.

The app needs to be given the list of sites appropriate for its token to make these decisions safely.

> It is up to the sites accepting the access tokens
> (the protected resources) to verify and enforce the scope.

A site cannot prevent a token being sent from a client app to the wrong site, because the right site never sees the traffic.

-- 
James Manger

---

From: David Recordon <[email-masked]>
Date: Thu, 6 May 2010 21:05:13 -0700

Hey James,
Do you have a specific example in mind where this either has been an issue
or will be an issue? Most client implementations I've seen of OAuth (and
technologies like OAuth) have a strong binding between the access token(s),
site they were issued by, and user they belong to. So I haven't heard of
this being a problem in the wild...

--David

On Thu, May 6, 2010 at 4:57 PM, Manger, James H <
[email-masked]> wrote:

> The default value for the “sites” field could be the token endpoint site
> (or the authorization endpoint site if a token endpoint isn’t used).
>
> For instance, if Facebook’s new API uses https://graph.facebook.com for
> all resources, tokens, and authorizations it could omit the “sites” field.
>
>
>
>
>
> http://www.ietf.org/mail-archive/web/oauth/current/msg01920.html,  though
> I mixed in additional ideas for formats and media type that are probable
> best covered in their own treads.
>
>
>
>
>
> --
>
> James Manger
>
>
>

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 7 May 2010 15:06:18 +1000

Every existing use of Cookies, HTTP Basic, and HTTP Digest relies on clients being told by the server about the sites at which the secret (cookie/password/token) can be used (and, more importantly, where is must not be used). This occurs without requiring service-specific knowledge in the client app. OAuth aims to replace some of these uses.

HTTP Basic authentication works safely from clients with no service-specific knowledge because the client knows not to send the password it gets from the user to other sites.

HTTP Digest authentication allows a password to used to across a set of domains specified in a WWW-Authenticate response header, but the password will not be used at arbitrary other sites.

Cookies are sent in requests to the same site, sites with the same parent, or only https sites, depending on details from the service when setting the cookie.

To date, OAuth has assumed every client app has lots of service-specific knowledge to make these choices. OAuth needs to remove the need for so much service-specific knowledge to be as interoperable as other standard auth mechanism, otherwise it is a poor replacement.

--

James Manger

From: David Recordon [mailto:[email-masked]]
Sent: Friday, 7 May 2010 2:05 PM
To: Manger, James H
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Indicating sites where a token is valid

Hey James,

Do you have a specific example in mind where this either has been an issue or will be an issue? Most client implementations I've seen of OAuth (and technologies like OAuth) have a strong binding between the access token(s), site they were issued by, and user they belong to. So I haven't heard of this being a problem in the wild...

--David

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 7 May 2010 15:21:45 +1000

How should an OAuth client app behave when it gets an HTTP redirect on requesting a protected resource?

Similarly, how should it behave when it follows any other link in a response?

Obviously it should make a new request to the URI in the redirect or link — that is normal HTTP and hypertext behaviour.

The question is does the token get sent with the new request?

I think the spec needs to provide an answer, even if it isn’t my suggestion of an “sites” list when a token is issued.

--

James Manger

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 07 May 2010 07:32:12 +0200

what about an additional realm response value?

If there is a binding between realm and token, the client can decide 
based on the realm attribute discovered using a WWW-Authenticate 
response which token to use.

regards,
Torsten.

Am 07.05.2010 07:06, schrieb Manger, James H:
>
> Every existing use of Cookies, HTTP Basic, and HTTP Digest relies on 
> clients being told by the server about the sites at which the secret 
> (cookie/password/token) can be used (and, more importantly, where is 
> must not be used). This occurs without requiring service-specific 
> knowledge in the client app. OAuth aims to replace some of these uses.
>
> HTTP Basic authentication works safely from clients with no 
> service-specific knowledge because the client knows not to send the 
> password it gets from the user to other sites.
>
> HTTP Digest authentication allows a password to used to across a set 
> of domains specified in a WWW-Authenticate response header, but the 
> password will not be used at arbitrary other sites.
>
> Cookies are sent in requests to the same site, sites with the same 
> parent, or only https sites, depending on details from the service 
> when setting the cookie.
>
> To date, OAuth has assumed every client app has lots of 
> service-specific knowledge to make these choices. OAuth needs to 
> remove the need for so much service-specific knowledge to be as 
> interoperable as other standard auth mechanism, otherwise it is a poor 
> replacement.
>
> -- 
>
> James Manger
>
> *From:* David Recordon [mailto:[email-masked]]
> *Sent:* Friday, 7 May 2010 2:05 PM
> *To:* Manger, James H
> *Cc:* OAuth WG
> *Subject:* Re: [OAUTH-WG] Indicating sites where a token is valid
>
> Hey James,
>
> Do you have a specific example in mind where this either has been an 
> issue or will be an issue? Most client implementations I've seen of 
> OAuth (and technologies like OAuth) have a strong binding between the 
> access token(s), site they were issued by, and user they belong to. So 
> I haven't heard of this being a problem in the wild...
>
> --David
>
>

---

From: David Recordon <[email-masked]>
Date: Thu, 6 May 2010 22:35:55 -0700

Why wouldn't the client send the token with the new request? If I'm trying
to access https://api.example.com/pr?access_token=loin21op and I get a 301
response, I'll need to follow that if I want any chance of accessing the
protected resource.

Maybe we're saying the same thing?

On Thu, May 6, 2010 at 10:21 PM, Manger, James H <
[email-masked]> wrote:

> Obviously it should make a new request to the URI in the redirect or link —
> that is normal HTTP and hypertext behaviour.
>
> I think the spec needs to provide an answer, even if it isn’t my suggestion
> of an “sites” list when a token is issued.
>
>
>
> --
>
> James Manger
>

---

From: Luke Shepard <[email-masked]>
Date: Thu, 6 May 2010 22:51:33 -0700

It's not really up to the client. If https://api.example.com/pr?access_token=loin21op redirects to https://api.otherapi.com/somethingelse?access_token=loin21op, then I just need to follow the redirect - no decisions to be made by the client. Many low-level HTTP libraries will just do this automatically. There are already facilities to warn if you try to redirect from an https url to an http one.

I think the difference between your cookie example and OAuth token is that cookies are automatically sent on every request, so there have to be rules about when they are automatically appended. OAuth access tokens aren't the same thing - they are explicitly added by developers on each request, so we don't need to overspecify rules in the protocol that should be handled by developers.

On May 6, 2010, at 10:35 PM, David Recordon wrote:

Why wouldn't the client send the token with the new request? If I'm trying to access https://api.example.com/pr?access_token=loin21op and I get a 301 response, I'll need to follow that if I want any chance of accessing the protected resource.

On Thu, May 6, 2010 at 10:21 PM, Manger, James H <[email-masked]<mailto:[email-masked]>> wrote:
How should an OAuth client app behave when it gets an HTTP redirect on requesting a protected resource?
Similarly, how should it behave when it follows any other link in a response?

--
James Manger

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

<ATT00001..txt>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 7 May 2010 08:00:18 +0200

in the same way as BASIC authorization headers are added to requests  
based on the associated realm, a Oauth library could automatically add  
tokens based in the realm obtained from WWW-Authenticate response  
header.

Regards,
Torsten.

Am 07.05.2010 um 07:51 schrieb Luke Shepard <[email-masked]>:

> It's not really up to the client. If https://api.example.com/pr?access_token=loin21op 
>  redirects to https://api.otherapi.com/somethingelse?access_token=loin21op 
> , then I just need to follow the redirect - no decisions to be made  
> by the client. Many low-level HTTP libraries will just do this  
> automatically. There are already facilities to warn if you try to  
> redirect from an https url to an http one.
>
> I think the difference between your cookie example and OAuth token  
> is that cookies are automatically sent on every request, so there  
> have to be rules about when they are automatically appended. OAuth  
> access tokens aren't the same thing - they are explicitly added by  
> developers on each request, so we don't need to overspecify rules in  
> the protocol that should be handled by developers.
>
>
>> Why wouldn't the client send the token with the new request? If I'm  
>> trying to access https://api.example.com/pr?access_token=loin21op  
>> and I get a 301 response, I'll need to follow that if I want any  
>> chance of accessing the protected resource.
>>
>> On Thu, May 6, 2010 at 10:21 PM, Manger, James H <[email-masked] 
>> > wrote:
>> Obviously it should make a new request to the URI in the redirect  
>> or link — that is normal HTTP and hypertext behaviour.
>>
>> I think the spec needs to provide an answer, even if it isn’t my s 
>> uggestion of an “sites” list when a token is issued.
>>
>>
>> --
>>
>> James Manger
>>
>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 7 May 2010 08:06:03 +0200

Additionally, I would propose to indicate the scope associated with a  
token to the client using a scope response parameter. This is  
especially useful (1) if the client did not pass a scope parameter but  
the server decided to associate a scope based on its policy or (2) if  
the user decided to authorize a subset of the requested scope only.

Regards,
Torsten.

Am 07.05.2010 um 07:32 schrieb Torsten Lodderstedt <[email-masked] 
 >:

>> Every existing use of Cookies, HTTP Basic, and HTTP Digest relies  
>> on clients being told by the server about the sites at which the  
>> secret (cookie/password/token) can be used (and, more importantly,  
>> where is must not be used). This occurs without requiring service- 
>> specific knowledge in the client app. OAuth aims to replace some of  
>> these uses.
>>
>> HTTP Basic authentication works safely from clients with no service- 
>> specific knowledge because the client knows not to send the  
>> HTTP Digest authentication allows a password to used to across a  
>> set of domains specified in a WWW-Authenticate response header, but  
>> the password will not be used at arbitrary other sites.
>>
>> To date, OAuth has assumed every client app has lots of service- 
>> specific knowledge to make these choices. OAuth needs to remove the  
>> need for so much service-specific knowledge to be as interoperable  
>> as other standard auth mechanism, otherwise it is a poor replacement.
>>
>> --
>> James Manger
>>
>> Do you have a specific example in mind where this either has been  
>> an issue or will be an issue? Most client implementations I've seen  
>> of OAuth (and technologies like OAuth) have a strong binding  
>> between the access token(s), site they were issued by, and user  
>> they belong to. So I haven't heard of this being a problem in the  
>> wild...
>>
>> --David
>>
>>

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 7 May 2010 16:08:10 +1000

> I think the difference between your cookie example and OAuth token is that cookies are automatically sent on every request, so there have to be rules about when they are automatically appended. OAu…

It is not just cookies, but HTTP Basic, HTTP Digest, NTLM etc are automatically sent on every request. In fact, I suspect most auth schemes are automatically applied. OAuth should not be any different. I hope decent libraries allow an OAuth token to be configured orthogonally to the code that actually makes the API requests.

Even if tokens are “explicitly added by developers on each requests”, the developers need to know which requests this applies to. A cornerstone of hypertext is making request based on links in responses. How does an app know if a link it finds in a response is part of the same API (so the token should be added) or an “external” link?

-- 

James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 7 May 2010 16:09:40 +1000

> Why wouldn't the client send the token with the new request? If I'm trying to access https://api.example.com/pr?access_token=loin21op and I get a 301 response, I'll need to follow that if I want an…

If https://api.example.com/pr?access_token=loin21op responses with “Location: http://evil.com/log” should the client get http://evil.com/log or http://evil.com/log?access_token=loin21op? Surely the later is potentially insecure. I don’t think we can assume (mandate) that services only redirect to “good” sites. We certainly can’t assume (mandate) that links in the content on the response are to “good” sites.

The answer is a bit easier if the token is passed as a query param (like with Facebook) -- as the client could rely on the service to include or omit the token param in the redirect/link URI as appropriate. It is less obvious with an Authorization header, or POST is used.

--

James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 7 May 2010 16:14:06 +1000

> what about an additional realm response value?

My original suggestion(http://www.ietf.org/mail-archive/web/oauth/current/msg01920.html) had a “realm” in addition to “sites”. I still think that should be present (though more to match the HTTP auth model (RFC2617) than an expectation that it will be used by most services).

> If there is a binding between realm and token, the client can decide based on the realm attribute discovered using a WWW-Authenticate response which token to use.

“realm” is not sufficient, however. A “realm” doesn’t stop you sending a token to a bad site. Even if an app makes and unauthenticated call first, there is nothing to stop the bad site responding with a WWW-Auth header with the right “realm” value so the client app will reveal the token.

--

James Manger

---

From: David Recordon <[email-masked]>
Date: Thu, 6 May 2010 23:15:14 -0700

Don't you have larger problems if your protected resources are compromised?
You might want to revoke access tokens or take the Google/Yahoo! model of
them expiring frequently with refresh tokens.

On Thu, May 6, 2010 at 11:09 PM, Manger, James H <
[email-masked]> wrote:

> trying to access https://api.example.com/pr?access_token=loin21op and I
> get a 301 response, I'll need to follow that if I want any chance of
> accessing the protected resource.
>
>
>
>
>
> If https://api.example.com/pr?access_token=loin21op responses with
> “Location: http://evil.com/log” should the client get http://evil.com/logor
> http://evil.com/log?access_token=loin21op? Surely the later is potentially
> insecure. I don’t think we can assume (mandate) that services only redirect
> to “good” sites. We certainly can’t assume (mandate) that links in the
> content on the response are to “good” sites.
>
>
>
> The answer is a bit easier if the token is passed as a query param (like
> with Facebook) -- as the client could rely on the service to include or omit
> the token param in the redirect/link URI as appropriate. It is less obvious
> with an Authorization header, or POST is used.
>
>
>
> --
>
> James Manger
>

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 7 May 2010 16:28:08 +1000

> Don't you have larger problems if your protected resources are compromised?

There is no compromise.

It is perfectly normal for a service to return content with links to arbitrary other sites.

Even redirects to arbitrary other sites (open redirectors) — thought they cause some issues — don’t mean the protected resources are compromised.

It just means clients need to be careful when following links and redirects on the web, and they need the right info to be able to be careful (such as when to include a token).

All the “connections” in the Facebook API example shown below are to Facebook. If Facebook allowed user-generated values for some of these that could point to other sites, it wouldn’t mean Facebook was compromised technically, but it would mean a token should be include when getting some but not others.

https://graph.facebook.com/btaylor?metadata=1

{

   "id": "220439",

   "name": "Bret Taylor",

   "first_name": "Bret",

   "last_name": "Taylor",

   "link": "http://www.facebook.com/btaylor",

   "location": {

      "id": 109650795719651,

      "name": "Los Gatos, California"

   },

   "gender": "male",

   "metadata": {

      "connections": {

         "home": "https://graph.facebook.com/btaylor/home",

         "feed": "https://graph.facebook.com/btaylor/feed",

         "friends": "https://graph.facebook.com/btaylor/friends",

         "family": "https://graph.facebook.com/btaylor/family",

         "activities": "https://graph.facebook.com/btaylor/activities",

         "interests": "https://graph.facebook.com/btaylor/interests",

         "music": "https://graph.facebook.com/btaylor/music",

         "books": "https://graph.facebook.com/btaylor/books",

         "movies": "https://graph.facebook.com/btaylor/movies",

         "television": "https://graph.facebook.com/btaylor/television",

         "likes": "https://graph.facebook.com/btaylor/likes",

         "posts": "https://graph.facebook.com/btaylor/posts",

         "tagged": "https://graph.facebook.com/btaylor/tagged",

         "statuses": "https://graph.facebook.com/btaylor/statuses",

         "links": "https://graph.facebook.com/btaylor/links",

         "notes": "https://graph.facebook.com/btaylor/notes",

         "photos": "https://graph.facebook.com/btaylor/photos",

         "albums": "https://graph.facebook.com/btaylor/albums",

         "events": "https://graph.facebook.com/btaylor/events",

         "groups": "https://graph.facebook.com/btaylor/groups",

         "videos": "https://graph.facebook.com/btaylor/videos",

         "picture": "https://graph.facebook.com/btaylor/picture",

         "inbox": "https://graph.facebook.com/btaylor/inbox",

         "outbox": "https://graph.facebook.com/btaylor/outbox",

         "updates": "https://graph.facebook.com/btaylor/updates"

      }

   },

   "type": "user"

}

--

James Manger

---

From: David Recordon <[email-masked]>
Date: Thu, 6 May 2010 23:31:02 -0700

I thought this thread was about https://graph.facebook.com/btaylor returning
a HTTP redirect, not about following links returned within the result?

On Thu, May 6, 2010 at 11:28 PM, Manger, James H <
[email-masked]> wrote:

> Even redirects to arbitrary other sites (open redirectors) — thought they
> cause some issues — don’t mean the protected resources are compromised.
>
> It just means clients need to be careful when following links and redirects
> on the web, and they need the right info to be able to be careful (such as
> when to include a token).
>
>
>
>
>
> All the “connections” in the Facebook API example shown below are to
> Facebook. If Facebook allowed user-generated values for some of these that
> could point to other sites, it wouldn’t mean Facebook was compromised
> technically, but it would mean a token should be include when getting some
> but not others.
>
>
>

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 7 May 2010 16:41:37 +1000

> I thought this thread was about https://graph.facebook.com/btaylor returning a HTTP redirect, not about following links returned within the result?

Opps. I started a separate thread then “crossed the beams” (I am not sure that there is a fundamental difference between redirects and other links in responses in this context).

Are you suggesting the rule should be “always include a token when following an HTTP redirect”, and some other rule(s) for other links (perhaps application-specific)? This is possible (if the spec explicitly states it), but I think it is a dangerous approach and not a good match for other web technologies.

--

James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 7 May 2010 16:46:14 +1000

I noticed the following text in draft-ietf-oauth-v2-02 (section 7 Accessing a Protected Resource):

“Clients SHOULD NOT make authenticated requests with an access token

   to unfamiliar resource servers, especially when using bearer tokens,

   regardless of the presence of a secure channel.”

A “sites” parameter would allow a client app can tell when it is about to access an “unfamiliar resource server”: an “unfamiliar resource server” is a server not listed in the “sites” parameter (or not the same server as the authorization server if “sites” is absent).

Otherwise this “SHOULD NOT” looks pretty hard to test.

--

James Manger

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 07 May 2010 12:17:24 +0200

Am 07.05.2010 08:14, schrieb Manger, James H:
> My original 
> suggestion(http://www.ietf.org/mail-archive/web/oauth/current/msg01920.html) 
> had a “realm” in addition to “sites”. I still think that should be 
> present (though more to match the HTTP auth model (RFC2617) than an 
> expectation that it will be used by most services).
>
> “realm” is not sufficient, however. A “realm” doesn’t stop you sending 
> a token to a bad site. Even if an app makes and unauthenticated call 
> first, there is nothing to stop the bad site responding with a 
> WWW-Auth header with the right “realm” value so the client app will 
> reveal the token.
>
> -- 
>
> James Manger
>

I didn't have that threat on my radar screen so far, thank you for your 
advice.

Let me describe what I understood so far from this thread and your 
previous posting. I see two different scenarios:

1) Resource server controls token sites (context of the realm attribute)

The realm returned in a WWW-Authenticate header is by default valid 
within the resource servers site (scheme + host-Part of the URL?) only. 
This way, a bad site cannot automatically get access to tokens intended 
for other sites just by spoofing  the realm attribute. Using an 
additional "sites"-attribute in the WWW-Authenticate-Header, the 
resource server could indicate on which sites the given realm is 
considered equivalent. This broadens the context a realm is valid in. It 
is the resource server which authorizes the usage of tokens on other 
sites by the client. If the clients encounters the same realm on a site 
listed in "sites", it is authorized to automatically use the token there.

2) Authorization server controls token sites (context of token)

If I interpret your current proposal correctly, you suggest the 
authorization server may determine on which sites a particular token can 
be used. That way, the authorization server explicitly authorizes usage 
of tokens based on the trusted relationship between resource server and 
authorization server. This is an interesting proposal since it could be 
used to prevent any bad site from token abuse and unauthorized access to 
private user data. The later is especially relevant if unencrypted, 
self-contained bearer tokens are used.

Attack scenario:
Assumption: User X has an account with site "https://www.example.com" 
where he stores his private data
1) The users intends to configure its mobile OAuth client for access to 
"https://www.example.com", but unfortunately uses the wrong URL 
"https://www.bad_example.com" obtained from an attackers e-Mail
2) "http://www.bad_example.com" respondes with the authorization URL of 
the OAuth server of "https://www.example.com"
3) The user authorizes access for "https://www.example.com" (or at least 
believes to do so)
4) The client acquires an access token from the authorization server
5) The mobile client access "https://www.bad_example.com" using that 
access token
6) "https://www.bad_example.com" proxies the request to 
"https://www.example.com", so neither the user nor the service realize 
the problem

I see the following ways how "https://www.bad_example.com" could abuse 
the token:
a) It can access the users private data on "https://www.example.com" or 
deposite illegal files (file sharing).
b) It can read the private user data contained in the token

If we follow your proposal, the authorization server would respond with 
a response value of "sites": ["https://www.example.com"] in step (4). 
The client would detect the attack attempt and refuse to send any 
request with the token to "https://www.bad_example.com".

In my opinion, (1) improves security and eases the practicability of 
OAuth2 in scenarios with multiple sites and (2) is a significant 
security improvement. I think, both scenarios should be addressed by the WG.

Any thoughts?

regards,
Torsten.

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 7 May 2010 10:57:03 -0700

> A site cannot prevent a token being sent from a client app to the wrong site, because the right site never sees the traffic.

I see what you mean. As David commented, not sure if this is a problem
in real life. The resource that the client is trying to access should
not redirect to an untrusted resource which is not supposed to receive
access tokens.

If the resources responds with a redirect I think the client should
trust that and just do it.

Marius

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 7 May 2010 11:01:50 -0700

Returning a scope parameter with issued tokens is not a bad idea.

But this, and also the sites parameter suggested by James, can both
potentially be solved with a transparent token format. Such a token
can make explicit the:
- expiry time
- scopes
- sites
- etc.

The Simple Web Token spec goes along these lines. SWT has a parameter
called Audience, which I assumed would point to the client, but it
could also represent "sites".

Marius

On Thu, May 6, 2010 at 11:06 PM, Torsten Lodderstedt
<[email-masked]> wrote:
> Additionally, I would propose to indicate the scope associated with a token
> to the client using a scope response parameter. This is especially useful
> (1) if the client did not pass a scope parameter but the server decided to
> associate a scope based on its policy or (2) if the user decided to
> authorize a subset of the requested scope only.
> Regards,
> Torsten.
>
>
>
> Am 07.05.2010 um 07:32 schrieb Torsten Lodderstedt
> <[email-masked]>:
>
> If there is a binding between realm and token, the client can decide based
> on the realm attribute discovered using a WWW-Authenticate response which
> token to use.
>
> regards,
> Torsten.
>
> Every existing use of Cookies, HTTP Basic, and HTTP Digest relies on clients
> being told by the server about the sites at which the secret
> (cookie/password/token) can be used (and, more importantly, where is must
> not be used). This occurs without requiring service-specific knowledge in
> the client app. OAuth aims to replace some of these uses.
>
>
>
> HTTP Basic authentication works safely from clients with no service-specific
> knowledge because the client knows not to send the password it gets from the
> user to other sites.
>
>
>
> HTTP Digest authentication allows a password to used to across a set of
> domains specified in a WWW-Authenticate response header, but the password
> will not be used at arbitrary other sites.
>
>
>
> Cookies are sent in requests to the same site, sites with the same parent,
> or only https sites, depending on details from the service when setting the
> cookie.
>
>
>
>
>
> To date, OAuth has assumed every client app has lots of service-specific
> knowledge to make these choices. OAuth needs to remove the need for so much
> service-specific knowledge to be as interoperable as other standard auth
> mechanism, otherwise it is a poor replacement.
>
>
>
> --
>
> James Manger
>
>
>

---

From: David Recordon <[email-masked]>
Date: Fri, 7 May 2010 11:06:19 -0700

Using SWT for your access tokens seems like a reasonable way to resolve this
for servers which care.

On Fri, May 7, 2010 at 11:01 AM, Marius Scurtescu <[email-masked]>wrote:

> token
> based
> clients
> service-specific
> parent,
> issue

---

From: "Manger, James H" <[email-masked]>
Date: Sun, 9 May 2010 23:12:52 +1000

Marius

> ...not sure if this is a problem in real life.
> The resource that the client is trying to access should not redirect
> to an untrusted resource which is not supposed to receive access tokens.

This is a massive restriction on what a web service can do.
It breaks the web if a service cannot redirect to less trusted sites.

An service couldn't redirect to a content distribution network (CDN) -- even if using unguessable URIs (ie capabilities) -- without exposing tokens to the CDN.
After accepting a secure, authenticated POST a service couldn't return a 303 pointing at an standard (public) response on HTTP -- or the token would be exposed in the clear.
Google couldn't offer its "I'm feeling lucky" interface to apps.

--
James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Sun, 9 May 2010 23:51:47 +1000

David & Marius,

> Using SWT for your access tokens seems like a reasonable way to resolve this for servers which care.

SWT is completely the wrong solution for this issue, if I understand it correctly.

I haven’t followed the SWT work much, but my understanding is that it aids interop between authorization and resource servers by defining a token format. A crucial feature is a MAC, created by the authz server and verified by the resource server.

A client app cannot have the secret key required to verify the signature (MAC) in a SWT token. SWT is separate from WRAP (& OAuth) because it is a private matter between servers -- which the client does not have to know anything about.

The commonality between this issue (“sites” token response param) and SWT is that client apps and resource servers need to know some similar information about a token: such as where & when it can be used.

Theoretically I guess we could mandate something like SWT (fleshed out with specifics) for tokens so clients and resource servers can get the info they need from the same field *in* the token. However, tokens that are opaque to clients (with the info they need in separate fields) is a much better architecture (less coupling), even if some info gets repeated.

P.S. I found SWT-v0.9.5 at http://groups.google.com/group/oauth-wrap-wg/files.

--

James Manger

From: [email-masked] [mailto:[email-masked]] On Behalf Of David Recordon
Sent: Saturday, 8 May 2010 4:06 AM
To: Marius Scurtescu
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Indicating sites where a token is valid

Using SWT for your access tokens seems like a reasonable way to resolve this for servers which care.

On Fri, May 7, 2010 at 11:01 AM, Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:

Marius

---

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

Torsten,

Thanks for your analysis.

> In my opinion, (1) improves security and eases the practicability of OAuth2 in scenarios with multiple sites and (2) is a significant security improvement. I think, both scenarios should be addressed by the WG.

Scenario 1 is basically how HTTP Digest works -- using a "domains" param, which is a list of URI prefixes.

If a resource server is delegating to an authz server, it may as well also rely on the authz server to indicate "realm" values that are equivalent across multiple resource servers.
That is, I think it is useful to return "sites" and "realm" values in a token response from an authz server, but that it is not necessary to return "sites" in a 401 resource server response in OAuth.
One resource server may well not know about all the other resource servers.

--
James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 9 May 2010 14:29:15 -0700

The idea of embedding this information into the token is wrong. This is clearly token metadata and that information belongs alongside the token, just like 'expires_in'.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of David Recordon
Sent: Friday, May 07, 2010 11:06 AM
To: Marius Scurtescu
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Indicating sites where a token is valid

Marius

On Thu, May 6, 2010 at 11:06 PM, Torsten Lodderstedt
<[email-masked]<mailto:[email-masked]>> wrote:
> <[email-masked]<mailto:[email-masked]>>:
>
> From: David Recordon [mailto:[email-masked]<mailto:[email-masked]>]

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 9 May 2010 14:29:58 -0700

Add some sort of wildcard support and I think this looks good.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Thursday, May 06, 2010 4:58 PM
To: OAuth WG
Subject: [OAUTH-WG] Indicating sites where a token is valid

--
James Manger

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 10 May 2010 08:18:33 -0400

+1

Any information that the client needs to care about should live outside the token.

 -- Justin

________________________________
From: [email-masked] [[email-masked]] On Behalf Of Eran Hammer-Lahav [[email-masked]]
Sent: Sunday, May 09, 2010 5:29 PM
To: David Recordon; Marius Scurtescu
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Indicating sites where a token is valid

The idea of embedding this information into the token is wrong. This is clearly token metadata and that information belongs alongside the token, just like ‘expires_in’.

EHL

Marius

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 10 May 2010 10:57:46 -0700

Hi James,

I was suggesting a transparent token format in general, SWT was just
an example. Yes, SWT does have a few problems:
- symmetric key encryption
- URL encoded name/value pairs as format

It can be easily extended to support public key crypto, but this will
help only key management between the authorization server and the
protected resources. The client does not really need to verify the
signature. If the token was compromised then the protected resource
will refuse it anyhow.

It was also suggested to use JSON and then web safe base64 for the format.

As a side note, I was thinking more about the suggested "sites"
parameter. In practice that sites where an access token can be used is
limited to what protected resources can decrypt or verify the token.
An access token cannot be really used at the wrong site. A "sites"
parameter could be a nice hint for the client, but not a security
requirement.

Marius

On Sun, May 9, 2010 at 6:51 AM, Manger, James H
<[email-masked]> wrote:
> I haven’t followed the SWT work much, but my understanding is that it aids
> interop between authorization and resource servers by defining a token
> format. A crucial feature is a MAC, created by the authz server and verified
> by the resource server.
>
>
>
> A client app cannot have the secret key required to verify the signature
> (MAC) in a SWT token. SWT is separate from WRAP (& OAuth) because it is a
> private matter between servers -- which the client does not have to know
> anything about.
>
>
>
> The commonality between this issue (“sites” token response param) and SWT is
> that client apps and resource servers need to know some similar information
> about a token: such as where & when it can be used.
>
>
>
> Theoretically I guess we could mandate something like SWT (fleshed out with
> specifics) for tokens so clients and resource servers can get the info they
> need from the same field *in* the token. However, tokens that are opaque to
> clients (with the info they need in separate fields) is a much better
> architecture (less coupling), even if some info gets repeated.
>
>
>
>
>
> P.S. I found SWT-v0.9.5 at
> http://groups.google.com/group/oauth-wrap-wg/files.
>
>
>
> --
>
> James Manger
>
>
>

---

From: Evan Gilbert <[email-masked]>
Date: Mon, 10 May 2010 16:30:14 -0700

I really like the idea behind the "sites" parameter

I think this idea relates closely to scopes and probably needs to be bound
more tightly to the inbound scope parameter. Both identify a set of
protected resources that can be accessed with the token - one is the
requested resources, the other is the granted resources. In both cases you
need to have a way to find a mapping from protected resource identifier ->
API endpoint you can call.

On Mon, May 10, 2010 at 5:18 AM, Richer, Justin P. <[email-masked]>wrote:

>  ------------------------------
> *From:* [email-masked] [[email-masked]] On Behalf Of Eran
> Hammer-Lahav [[email-masked]]
> *Sent:* Sunday, May 09, 2010 5:29 PM
> *To:* David Recordon; Marius Scurtescu
>
> *Cc:* OAuth WG
>   The idea of embedding this information into the token is wrong. This is
> clearly token metadata and that information belongs alongside the token,
> just like ‘expires_in’.
>
>
>
> EHL
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *David Recordon
> *Sent:* Friday, May 07, 2010 11:06 AM
> *To:* Marius Scurtescu
> *Cc:* OAuth WG

---

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

Marius,

> parameter could be a nice hint for the client, but not a security

A bearer token that goes to the wrong site can be used -- to access the protected resource on the right site -- so this is a total security failure, not a nice hint.

If the wrong site uses HTTP then the token is also exposed on the network -- so it has just been broadcast in the clear if you are using public wifi. Again a security failure.

-- 
James Manger

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 10 May 2010 16:50:56 -0700

> A bearer token that goes to the wrong site can be used -- to access the protected resource on the right site -- so this is a total security failure, not a nice hint.

Yes, you are right. I was thinking about information leak from the
token. But then again, how does the client end up making a request to
the wrong site?

> If the wrong site uses HTTP then the token is also exposed on the network -- so it has just been broadcast in the clear if you are using public wifi. Again a security failure.

Sure, but the "sites" parameter does not help in these cases.

Marius

---

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

Marius,

> But then again, how does the client end up making a request to
the wrong site?

The client follows a redirect or link. It doesn't know if the ultimate source of the new URI was the resource server’s internal logic, user-generated content, or a parameter in the request URI (eg an open redirector).

> Sure, but the "sites" parameter does not help in these cases.

"sites" does help. If its value was:
  "sites": ["https://api.example.com", "https://img.example.com"]
Then no HTTP URI matches so the token is never sent in the clear.

--
James Manger

---

From: David Recordon <[email-masked]>
Date: Mon, 10 May 2010 20:45:36 -0700

If the sites parameter is not specified, would it default to the
domain of the authorization server. If it is specified, then the valid
sites are what is explicitly listed. Wildcards would only be supported
for subdomains and it would be assumed that any resource on that
domain is valid.

Thus with the user endpoint being https://graph.facebook.com/oauth/authorize:

1) no sites parameter means the access token is only valid on
https://graph.facebook.com/*

2) sites key with a value of ["https://graph.facebook.com/"] means
that the access token is only valid on https://graph.facebook.com/*

3) sites key with a value of ["https://*.facebook.com/"] means that
https://graph.facebook.com/* and https://www.facebook.com/* would both
be valid (among other subdomains)

4) sites key with a value of ["https://graph.facebook.com/",
"https://api.facebook.com/"] means that only
https://graph.facebook.com/* and https://api.facebook.com/* would be
valid

5) sites key with a value of ["https://api.facebook.com/"] means that
the the token isn't valid on https://graph.facebook.com/ even though
that's the authorization server

Obviously the sites parameter isn't restricted to being on the same
domain, just used it that way for these examples. Am I understanding
the proposal correctly?

Thanks,
--David

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 11 May 2010 13:52:25 +1000

Correct. All your examples match my intention, David.

-- 
James Manger

-----Original Message-----
From: David Recordon [mailto:[email-masked]] 
Sent: Tuesday, 11 May 2010 1:46 PM
To: Eran Hammer-Lahav
Cc: Manger, James H; OAuth WG
Subject: Re: [OAUTH-WG] Indicating sites where a token is valid

Thanks,
--David

---

From: David Recordon <[email-masked]>
Date: Mon, 10 May 2010 21:06:01 -0700

Sweet, +1 then to adding this as an optional return parameter when
receiving an access token.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 11 May 2010 19:21:55 +0200

> One resource server may well not know about all the other resource servers.

So you suggest to return "sites" from the authz server only?

regards,
Torsten.

---

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

Hi James,

> The client follows a redirect or link. It doesn't know if the ultimate source of the new URI was the resource server’s internal logic, user-generated content, or a parameter in the request URI (eg…

If the protected resource sends a redirect instead of serving the
resource then probably it knows what it is doing.

Following links, how do you see that happening? Normally a client will
not follow links without understanding them and at the same time send
access tokens.

All I am saying is that IMO it is not very likely that redirects and
links will cause tokens to leak. I do agree that "sites" can help in
these cases, just not sure it is worth the complexity.

> Then no HTTP URI matches so the token is never sent in the clear.

Yes, but HTTP and WIFI can compromise tokens even if sent to the
proper sites. Right?

Marius

---

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

On Mon, May 10, 2010 at 8:45 PM, David Recordon <[email-masked]> wrote:
> domain of the authorization server.

What is the domain of the authz server? The authz server is defined by
two URLs, they may not have the same domain.

Marius

---

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

Marius,

> resource then probably it knows what it is doing.

Sure, the server knows what it is doing. However it is completely legitimate for a server to knowingly redirect to an external site, to a site configured by a user, to a site matching a search term etc.
The server knows whether a redirect (or link) might cross a security boundary, but the issue is how does the client know.

> not follow links without understanding them and at the same time send

A client app understands that’s a URI in an <img> tag or a Facebook "photos" link should lead to an image. It is far less obvious what the security context for that image is: is it part of the same API, or an arbitrary image on the Internet.

> Yes, but HTTP and WIFI can compromise tokens even if sent to the

Yes, but only if the server explicitly decided that particular token was suitable for sending in the clear and explicitly told the client so by including an HTTP string in the "sites" field.

Marius

---

From: Evan Gilbert <[email-masked]>
Date: Wed, 12 May 2010 12:51:05 -0700

> I really like the idea behind the "sites" parameter

I continue to like the idea behind the "sites" parameter, but think it may
be premature to add to the OAuth spec.

Clients need to know the following in advance:
1. The scope to use to request access to a protected resource
2. The API endpoint to call to access the the protected resource

Solving the question of what URL prefixes are valid to send the token to
seems like it needs to follow answers for #1 and #2 (or at least #2).

As an example, to support #2 we might want to return JSON configuration
about all of the APIs that are available ({'contacts.get': 'http:/...',
'activities.post': 'http://...'}). This would supersede the need for the
sites parameter.

(note: These are the types of issues I'd prefer to start as provisional
enhancements<http://groups.google.com/group/oauth-ietf-wg/browse_thread/thread/f33945621c935c9e>
)

>> must

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 13 May 2010 10:09:52 +1000

Evan,

> Solving the question of what URL prefixes are valid to send the token
> to seems like it needs to follow answers for #1 and #2 (or at least #2).

I agree that a client needs #2 to *start* using an API.
The issue is what the client needs as it follows redirects and links through the API and beyond.

> As an example, to support #2 we might want to return JSON
> configuration about all of the APIs that are available
> ({'contacts.get': 'http:/...', 'activities.post': 'http://...'}).
> This would supersede the need for the sites parameter.

I don't like this specific idea of mixing API discover with the credential format. It is a web-style approach though: the client follows links in a response. Such links in a response will not only occur at this initial point, they can appear anywhere in a web-style API. The client needs to know what to do (send token or not) at each point that a link appears -- "sites" answers this.

> I think this idea relates closely to scopes and probably needs to be bound more tightly to the inbound scope parameter. Both identify a set of protected resources that can be accessed with the token - one is the requested resources, the other is the granted resources.

This is not true.
Facebook scopes, for instance, are permissions not identities of protected resources. If you want (generic) clients to be able to list requested resources (by URI?) that needs a separate proposal, and probably can't use "scopes".

> In both cases you need to have a way to find a mapping
> from protected resource identifier -> API endpoint you can call.

Isn't a "protected resource identifier" the URI you GET/POST/PUT/DELETE to?

P.S. On #1, a client needs an authz URI to send a user to -- knowing the scope and a base URI is just one way to build such an authz URI, being given the authz URI is another.

--
James Manger

---

From: Evan Gilbert <[email-masked]>
Date: Wed, 12 May 2010 22:41:04 -0700

Thanks for the response - feedback inline...

> I don't like this specific idea of mixing API discover with the credential
> format.

Seems like if it's OK to send a list of valid "sites" for a credential it
should be OK to list the API endpoints.

Also, this discovery could be in a separate process - doesn't have to be
with the token response. The key point is that this discovery covers a lot
of the same grounds as the sites parameter, and it's hard  to define
semantics around a sites parameter without understanding the semantics of
scopes and API endpoints.

> It is a web-style approach though: the client follows links in a response.
> Such links in a response will not only occur at this initial point, they can
> appear anywhere in a web-style API. The client needs to know what to do
> (send token or not) at each point that a link appears -- "sites" answers
> this.

Clients need to more about these links (at least the response format). The
mechanism they use to find out about these links - documentation, discovery,
data returned with token request - could also provide the information about
whether a token should be sent to a particular API.

>
>
> > I think this idea relates closely to scopes and probably needs to be
> bound more tightly to the inbound scope parameter. Both identify a set of
> requested resources, the other is the granted resources.
>
> This is not true.
> Facebook scopes, for instance, are permissions not identities of protected
> resources. If you want (generic) clients to be able to list requested
> resources (by URI?) that needs a separate proposal, and probably can't use
> "scopes".
>

I was using "set of protected resources" to mean a permission.

I should be more concrete about the use cases I see. Let's assume there's an
API where there are two endpoints, each with an associated permission
- contacts.list permission ->
http://contacts.serviceprovider.com/contacts/list
- calendar.get permission ->
http://calendar.serviceprovider.com/calendar/get

If the response to an authorization request includes the authorized scopes
(contacts.list, calendar.get), then the "sites" parameter is redundant.

> P.S. On #1, a client needs an authz URI to send a user to -- knowing the
> scope and a base URI is just one way to build such an authz URI, being given
> the authz URI is another.
>
> --
> James Manger
>

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 13 May 2010 16:52:46 +1000

Evan,

> The key point is that this discovery covers a lot of the same grounds as the sites parameter, and it's hard  to define semantics around a sites parameter without understanding the semantics of scopes and API endpoints.

I strongly disagree. The semantics are crystal clear:
  "Here is a token. It is INSECURE to send it anywhere not in this list."
These semantics are useful regardless of what the API does, how the client is using it, or how much (or how little) the client knows about the API.

> Clients need to [know] more about these links (at least the response format).

That knowledge comes from other standards (HTML, Atom, wiki of rel values...) and is totally independent of whether a token should or should not be sent.

> The mechanism they use to find out about these links - documentation, discovery, data returned with token request - could also provide the information about whether a token should be sent to a particular API.

Could, but shouldn't and doesn't in practise.
It is much much better to have the information about how to use a token securely delivered at the same time & place as receiving that token, and with minimal assumptions about how much the client apps knows about the service.

> I should be more concrete about the use cases I see. Let's assume there's an API where there are two endpoints, each with an associated permission
> - contacts.list permission -> http://contacts.serviceprovider.com/contacts/list
> - calendar.get permission -> http://calendar.serviceprovider.com/calendar/get
>
> If the response to an authorization request includes the authorized scopes (contacts.list, calendar.get), then the "sites" parameter is redundant.

I'll admit that "sites" is redundant if a client has *perfect* knowledge about a service, but so is pretty much any standard at that point.

Consider a generic search spider tool that you point at http://calendar.serviceprovider.com/calendar/get. It can do its job with no knowledge about what "calendar.get" means -- but it still needs to know (as it spiders along) when it is safe to expose the token.

--
James Manger

---

From: Evan Gilbert <[email-masked]>
Date: Thu, 13 May 2010 09:00:27 -0700

On Wed, May 12, 2010 at 11:52 PM, Manger, James H <
[email-masked]> wrote:

> Evan,
>
> > The key point is that this discovery covers a lot of the same grounds as
> the sites parameter, and it's hard  to define semantics around a sites
> parameter without understanding the semantics of scopes and API endpoints.
>
> These semantics are useful regardless of what the API does, how the client
> is using it, or how much (or how little) the client knows about the API.
>

To expand - it's hard to define *useful* semantics around a sites parameter
without understanding the semantics of scopes and API endpoints. Yes, you
can define crystal clear semantics, but these are not useful unless they
work well with the way developers figure out the endpoints to call APIs.

> That knowledge comes from other standards (HTML, Atom, wiki of rel
> values...) and is totally independent of whether a token should or should
> not be sent.
>

In our use cases, clients almost always need to know more about the API:
- How to call directly - we have no API endpoints that are only arrived at
by links
- Response format of the data

>
>
> > The mechanism they use to find out about these links - documentation,
> discovery, data returned with token request - could also provide the
> information about whether a token should be sent to a particular API.
>
> It is much much better to have the information about how to use a token
> securely delivered at the same time & place as receiving that token, and
> with minimal assumptions about how much the client apps knows about the
> service.
>

So why wouldn't we return a list of specific API endpoints instead of a
"sites" parameter?

Developers are going to call the APIs endpoints that they know about. If
there is a conflict between this and the sites parameter, what should they
do? For example, if facebook returns a sites parameter "
https://unknown.facebook.com/", do we think the developer is going to not
try to use the access token on
https://graph.facebook.com/<https://graph.facebook.com/*>
 ?

Separating the concept of sites from API endpoints feels like a bad idea.
Discovery / docs will give you a list of URLs where you should send tokens.
The "sites" parameter will give you a list of URLs where you can send
tokens. This is redundant, and will lead to developers / libraries not
respecting the sites parameter. If developers / libraries don't respect it,
then the service can't rely on it for enforcing security.

Another note: Where do we anticipate clients storing the sites parameter in
the User-Agent flow? Right now the access token can be set as an HTTP cookie
by the client. Do we expect them to set a separate "sites" cookie and
respect this on their server when making requests? This seems complicated.

>
> > I should be more concrete about the use cases I see. Let's assume there's
> an API where there are two endpoints, each with an associated permission
> > If the response to an authorization request includes the authorized
> scopes (contacts.list, calendar.get), then the "sites" parameter is
> redundant.
>
> I'll admit that "sites" is redundant if a client has *perfect* knowledge
> about a service, but so is pretty much any standard at that point.
>
> Consider a generic search spider tool that you point at
> http://calendar.serviceprovider.com/calendar/get. It can do its job with
> no knowledge about what "calendar.get" means -- but it still needs to know
> (as it spiders along) when it is safe to expose the token.
>

How does the generic search spider know to call to
http://calendar.serviceprovider.com/calendar/get in the first place?

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 13 May 2010 09:08:51 -0700

You are trying to match a mechanism designed for automatic discovery with a system designed to require paperwork. It sounds like for your use cases, you will not be using this optional parameter and just document how to use your API (i.e. hardcode your security setup and API format).

The whole point of this is that the developer isn't involved. The library takes care of everything. All the developer does is ask to get a protected resource. The library will check if it already has a valid token for that resource (based on the security restrictions provided by the sites parameter, and the scope requirements - two very separate things).

So yes - if your developers have plenty of stuff to hardcode already, this adds little value.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Evan Gilbert
Sent: Thursday, May 13, 2010 9:00 AM
To: Manger, James H
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Indicating sites where a token is valid

On Wed, May 12, 2010 at 11:52 PM, Manger, James H <[email-masked]<mailto:[email-masked]>> wrote:
Evan,

To expand - it's hard to define *useful* semantics around a sites parameter without understanding the semantics of scopes and API endpoints. Yes, you can define crystal clear semantics, but these are not useful unless they work well with the way developers figure out the endpoints to call APIs.

In our use cases, clients almost always need to know more about the API:
- How to call directly - we have no API endpoints that are only arrived at by links
- Response format of the data

So why wouldn't we return a list of specific API endpoints instead of a "sites" parameter?

Developers are going to call the APIs endpoints that they know about. If there is a conflict between this and the sites parameter, what should they do? For example, if facebook returns a sites parameter "https://unknown.facebook.com/", do we think the developer is going to not try to use the access token on https://graph.facebook.com/<https://graph.facebook.com/*> ?

Separating the concept of sites from API endpoints feels like a bad idea. Discovery / docs will give you a list of URLs where you should send tokens. The "sites" parameter will give you a list of URLs where you can send tokens. This is redundant, and will lead to developers / libraries not respecting the sites parameter. If developers / libraries don't respect it, then the service can't rely on it for enforcing security.

Another note: Where do we anticipate clients storing the sites parameter in the User-Agent flow? Right now the access token can be set as an HTTP cookie by the client. Do we expect them to set a separate "sites" cookie and respect this on their server when making requests? This seems complicated.

How does the generic search spider know to call to http://calendar.serviceprovider.com/calendar/get in the first place?

--
James Manger

---

From: Evan Gilbert <[email-masked]>
Date: Thu, 13 May 2010 09:15:56 -0700

On Thu, May 13, 2010 at 9:08 AM, Eran Hammer-Lahav <[email-masked]>wrote:

> You are trying to match a mechanism designed for automatic discovery with a
> system designed to require paperwork. It sounds like for your use cases, you
> will not be using this optional parameter and just document how to use your
> API (i.e. hardcode your security setup and API format).
>

I'm saying it should be a fully automatic discovery or use paperwork. Having
an API return valid URL prefixes to send the token to without having an API
to determine the actual URLs you send tokens to seems odd.

>
>
> The whole point of this is that the developer isn’t involved. The library
> takes care of everything. All the developer does is ask to get a protected
> resource. The library will check if it already has a valid token for that
> resource (based on the security restrictions provided by the sites
> parameter, and the scope requirements – two very separate things).
>

This is an incomplete mechanism for automatic discovery. How does the
developer find out where to ask for the protected resource in the first
place?

>
>
> So yes – if your developers have plenty of stuff to hardcode already, this
> adds little value.
>
>
>
> EHL
>
>
>
> Of *Evan Gilbert
> *Sent:* Thursday, May 13, 2010 9:00 AM
>
> *To:* Manger, James H
> *Cc:* OAuth WG
> try to use the access token on https://graph.facebook.com/<https://graph.facebook.com/*>
>  ?
>
>
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 13 May 2010 09:30:05 -0700

Today when I cut/paste a URI of an image using Basic auth, the browser knows exactly what to do. I want to do the same with an OAuth-protected image. Saying that there aren't standards API out there to benefit from this is incorrect. There are plenty.

This is complete discovery for the authentication layer. The rest doesn't belong here, the same way this doesn't belong as part of the API specification.

EHL

From: Evan Gilbert [mailto:[email-masked]]
Sent: Thursday, May 13, 2010 9:16 AM
To: Eran Hammer-Lahav
Cc: Manger, James H; OAuth WG
Subject: Re: [OAUTH-WG] Indicating sites where a token is valid

On Thu, May 13, 2010 at 9:08 AM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
You are trying to match a mechanism designed for automatic discovery with a system designed to require paperwork. It sounds like for your use cases, you will not be using this optional parameter and just document how to use your API (i.e. hardcode your security setup and API format).

I'm saying it should be a fully automatic discovery or use paperwork. Having an API return valid URL prefixes to send the token to without having an API to determine the actual URLs you send tokens to seems odd.

This is an incomplete mechanism for automatic discovery. How does the developer find out where to ask for the protected resource in the first place?

EHL

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Evan Gilbert
Sent: Thursday, May 13, 2010 9:00 AM

To: Manger, James H
Cc: OAuth WG

--
James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 14 May 2010 09:54:42 +1000

Evan,

> we have no API endpoints that are only arrived at by links

This doesn't sound very web-friendly. Your APIs don't have to follow a web-style, but an IETF spec should support web-style APIs.

I am a bit surprised with your statement as a whole lot of Google APIs do have API endpoints arrived at by links. I thought most Google Data APIs followed the Atom Publishing Protocol. This uses links extensively. For instance, <link rel="edit" href="..."/> tells the client the API endpoint to at which an entry can be updated.

There are lots and lots of <link rel="..." href="..."/> relations defined: in the Atom spec, in the APP spec, in GData docs (not specific to particular APIs) etc.

Definitions of none of these link relations state that they MUST or MUST NOT be part of the same API.

> Another note: Where do we anticipate clients storing the sites parameter in the User-Agent flow? Right now the access token can be set as an HTTP cookie by the client. Do we expect them to set a se…

Presumably the client needs to store the access token, the expiry date, perhaps the scopes etc. Easy solution: store the base64-encoding of the JSON representation of the token details.

--
James Manger

---

From: Evan Gilbert <[email-masked]>
Date: Thu, 13 May 2010 17:02:23 -0700

On Thu, May 13, 2010 at 4:54 PM, Manger, James H <
[email-masked]> wrote:

> This doesn't sound very web-friendly. Your APIs don't have to follow a
> web-style, but an IETF spec should support web-style APIs.

I didn't say that our endpoints can't be arrived at by links. I said our
APIs all can be called directly and clients need to know how to call them
directly.

Clients need to have a way of finding out:
1. The available endpoint URLs, and
2. The scopes to ask for to access these URLs

"sites" by itself is insufficient to be useful to our developers.

> I am a bit surprised with your statement as a whole lot of Google APIs do
> have API endpoints arrived at by links. I thought most Google Data APIs
> followed the Atom Publishing Protocol. This uses links extensively. For
> instance, <link rel="edit" href="..."/> tells the client the API endpoint to
> at which an entry can be updated.
>
> There are lots and lots of <link rel="..." href="..."/> relations defined:
> in the Atom spec, in the APP spec, in GData docs (not specific to particular
> APIs) etc.
>
> > Another note: Where do we anticipate clients storing the sites parameter
> in the User-Agent flow? Right now the access token can be set as an HTTP
> cookie by the client. Do we expect them to set a separate "sites" cookie and
> Presumably the client needs to store the access token, the expiry date,
> perhaps the scopes etc. Easy solution: store the base64-encoding of the JSON
> representation of the token details.
>

Currently the client side flow is really simple:
1. Set access token as a cookie, with
2. An expiration matching the expires_in time

Are you suggesting the client parse the URL parameters, create a JSON block,
base64 encode the block, and then write an HTTP cookie?

---

From: Brian Eaton <[email-masked]>
Date: Fri, 14 May 2010 08:45:30 -0700

On Thu, May 13, 2010 at 9:00 AM, Evan Gilbert <[email-masked]> wrote:
>> http://calendar.serviceprovider.com/calendar/get. It can do its job with no
>> knowledge about what "calendar.get" means -- but it still needs to know (as
>> it spiders along) when it is safe to expose the token.
>

I'm a bit confused by this example.

James, can you explain what you mean by "generic search spider tool"?

---

From: "Manger, James H" <[email-masked]>
Date: Sat, 15 May 2010 10:56:59 +1000

Brian,

> James, can you explain what you mean by "generic search spider tool"?

A tool that builds a search index.
You point it a URI; it fetches the content; indexes it; follows any links in the content to more content; indexes that; and continues.
The tool understands HTTP; it knows how to find links in common media types (<a href=...>, <link ...>, etc); but it doesn't have much API-specific knowledge (it doesn't know or care if it is indexing a calendar, a personal blog, a social graph, a doc repository, all of the above etc).

If some of the content requires user consent to access (ie returns WWW-Auth.: Token user-uri="..."), the tool performs an OAuth flow and continues.

The tool needs some rule so it doesn't try to index the whole Internet. For example: index at most 500 pages; download no more than 10MB; finish in 5 min; only following links to a depth of 3; stay within example.com. This rule does not necessarily have anything to do with any security boundaries.

The crucial features of the tool are that it knows enough about HTTP and data formats to follow redirects & links; but it doesn't have service-specific knowledge to know understand service-specific scopes (eg "calendar.get") or the boundaries of specific APIs.

There are lots of tools in this category. It matches the architecture of the web.

Other examples of such tools might be:
* a backup tool -- point it at your atom feeds and it copies the content (and the linked stylesheets, scripts, images...)
* perhaps cURL -- do anything on the web
* a web browser

I hope this clears some confusion.

--
James Manger

---

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

Not sure if you intended this, but you are mixing user present and user not
present access control.

I do NOT think we want OAuth protected images to be the same as Basic auth
protected images. I do think OpenID protected images and Basic auth are
similar. With OAuth today, the user has granted explicit permission at a
particular resource, not any resource the user may have access to.

-- Dick

On Thu, May 13, 2010 at 9:30 AM, Eran Hammer-Lahav <[email-masked]>wrote:

> Today when I cut/paste a URI of an image using Basic auth, the browser
> knows exactly what to do. I want to do the same with an OAuth-protected
> image. Saying that there aren’t standards API out there to benefit from this
> is incorrect. There are plenty.
>
>
>
> This is complete discovery for the authentication layer. The rest doesn’t
> belong here, the same way this doesn’t belong as part of the API
> specification.
>
>
>
> EHL
>
>
>
> *From:* Evan Gilbert [mailto:[email-masked]]
> *Sent:* Thursday, May 13, 2010 9:16 AM
> *To:* Eran Hammer-Lahav
> *Cc:* Manger, James H; OAuth WG
>
> I'm saying it should be a fully automatic discovery or use paperwork.
> Having an API return valid URL prefixes to send the token to without having
> an API to determine the actual URLs you send tokens to seems odd.
>
>
>

---

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

Why can't an image be protected with both Basic and OAuth? In this case the browser is the OAuth client.

EHL

From: Dick Hardt [mailto:[email-masked]]
Sent: Sunday, May 16, 2010 11:38 AM
To: Eran Hammer-Lahav
Cc: Evan Gilbert; OAuth WG
Subject: Re: [OAUTH-WG] Indicating sites where a token is valid

Not sure if you intended this, but you are mixing user present and user not present access control.

I do NOT think we want OAuth protected images to be the same as Basic auth protected images. I do think OpenID protected images and Basic auth are similar. With OAuth today, the user has granted explicit permission at a particular resource, not any resource the user may have access to.

-- Dick

On Thu, May 13, 2010 at 9:30 AM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
Today when I cut/paste a URI of an image using Basic auth, the browser knows exactly what to do. I want to do the same with an OAuth-protected image. Saying that there aren't standards API out there to benefit from this is incorrect. There are plenty.

EHL

From: Evan Gilbert [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, May 13, 2010 9:16 AM
To: Eran Hammer-Lahav
Cc: Manger, James H; OAuth WG

EHL

To: Manger, James H
Cc: OAuth WG

--
James Manger

---

From: Dick Hardt <[email-masked]>
Date: Thu, 20 May 2010 09:05:46 -0700

The image can be protected by both. Do you expect OAuth to be used with user present in the browser?

On 2010-05-17, at 11:20 PM, Eran Hammer-Lahav wrote:

> Why can’t an image be protected with both Basic and OAuth? In this case the browser is the OAuth client.
>  
> EHL
>  
> On Thu, May 13, 2010 at 9:30 AM, Eran Hammer-Lahav <[email-masked]> wrote:
> Today when I cut/paste a URI of an image using Basic auth, the browser knows exactly what to do. I want to do the same with an OAuth-protected image. Saying that there aren’t standards API out there to benefit from this is incorrect. There are plenty.
>  
> This is complete discovery for the authentication layer. The rest doesn’t belong here, the same way this doesn’t belong as part of the API specification.
>  
> EHL
>  
> On Thu, May 13, 2010 at 9:08 AM, Eran Hammer-Lahav <[email-masked]> wrote:
> The whole point of this is that the developer isn’t involved. The library takes care of everything. All the developer does is ask to get a protected resource. The library will check if it already has a valid token for that resource (based on the security restrictions provided by the sites parameter, and the scope requirements – two very separate things).
>  
> So yes – if your developers have plenty of stuff to hardcode already, this adds little value.
>  
> EHL
>  
> On Wed, May 12, 2010 at 11:52 PM, Manger, James H <[email-masked]> wrote:
> Evan,
> 
> Developers are going to call the APIs endpoints that they know about. If there is a conflict between this and the sites parameter, what should they do? For example, if facebook returns a sites parameter "https://unknown.facebook.com/", do we think the developer is going to not try to use the access token on https://graph.facebook.com/ ? 
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 20 May 2010 09:54:55 -0700

Yes. The user is delegating access to the browser.

EHL

On 5/20/10 9:05 AM, "Dick Hardt" <[email-masked]> wrote:

EHL

-- Dick

EHL

EHL

To: Manger, James H
Cc: OAuth WG

Developers are going to call the APIs endpoints that they know about. If there is a conflict between this and the sites parameter, what should they do? For example, if facebook returns a sites parameter "https://unknown.facebook.com/", do we think the developer is going to not try to use the access token on https://graph.facebook.com/ <https://graph.facebook.com/*> ?

--
James Manger