Subject: [OAUTH-WG] Comments on Web Callback & Client Flow

From: Evan Gilbert <[email-masked]>
Date: Mon, 5 Apr 2010 16:28:33 -0700

A few comments on the Web Server and Web Client flow from the draft
2.0 spec<http://github.com/theRazorBlade/draft-ietf-oauth/>
.

Evan

----

2.4.1 Web Callback Flow & 2.4.2 Web Client Flow
In both flows, the authorization server should be able redirect back to the
callback URI without interacting directly with the resource owner if access
has already been approved.  This is not ruled out in the current language
but it could be made cleaner.

Suggested rewording - change

"After receiving an authorization decision from the resource owner, the
server redirects the resource owner to the callback URI."

  to

"If the client is already approved or denied for access to the protected
resource, the authorization service MAY redirect the resource owner to the
callback URI immediately. If not, the authorization service SHOULD ask the
resource owner for an authorization decision and after receiving the
decision redirect the resource owner to the callback URI."

----

2.4.1 Web Callback Flow & 2.4.2 Web Client Flow
We should have an OPTIONAL username parameter:
username
  The resource owner's username. The authorization server MUST only send
back refresh tokens or access tokens for this user.

This is useful for clients where a user is already logged into a 3rd party
web site with a specific account, and the client wants the authorization to
match the specific user.

----

2.4.2 Web Client Flow
Sending an access token as a query parameter is dangerous from a security
perspective - these tokens are leaked via referrers and server logs. In
previous WRAP discussions, it was felt that we should have a strong
recommendation to use the URL fragment.

Suggested wording:
Client SHOULD send a callback URI with a query fragment, and authorization
server MAY reject callback URLs without a fragment for security reasons.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 6 Apr 2010 00:21:23 -0700

Hi Evan,

On 4/5/10 4:28 PM, "Evan Gilbert" <[email-masked]> wrote:

> has already been approved.  This is not ruled out in the current language but
> it could be made cleaner. 
> 
> "After receiving an authorization decision from the resource owner, the server
> redirects the resource owner to the callback URI."
> 
>   to
> 

I opted for a simpler change:

'After receiving (or establishing via other means) an authorization
decision'

>   The resource owner's username. The authorization server MUST only send back
> refresh tokens or access tokens for this user.
> 
> This is useful for clients where a user is already logged into a 3rd party web
> site with a specific account, and the client wants the authorization to match
> the specific user.

I think introducing the concept of user identity is more complex than just a
username parameter. I agree that it can be useful but we need a more
detailed discussion about this before we add it.

> server MAY reject callback URLs without a fragment for security reasons.

Why not require it?

EHL

---

From: Evan Gilbert <[email-masked]>
Date: Tue, 6 Apr 2010 07:04:44 -0700

On Tue, Apr 6, 2010 at 12:21 AM, Eran Hammer-Lahav <[email-masked]>wrote:

> server

Sounds great

> back

I agree issues around user identity are complex.

Would it help to spin up a separate discussion thread on this one issue?

> > server MAY reject callback URLs without a fragment for security reasons.

I made the assumption that someone had use cases that drove the examples in
the spec.

I would be OK with requiring it.

---

From: David Recordon <[email-masked]>
Date: Tue, 6 Apr 2010 07:53:22 -0700

The web client flow was intended to require either a fragment or SSL
(or optionally both).

On Tue, Apr 6, 2010 at 7:04 AM, Evan Gilbert <[email-masked]> wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Evan Gilbert <[email-masked]>
Date: Tue, 6 Apr 2010 08:45:53 -0700

> The web client flow was intended to require either a fragment or SSL

Even with SSL, referrer leaks seem to be a danger (I think https referrers
are still sent). Are we worried about this?

> >> > In both flows, the authorization server should be able redirect back
> to
> >> > the
> >> > site with a specific account, and the client wants the authorization
> to
> >> > match
> >> > the specific user.
> >>
> >> I think introducing the concept of user identity is more complex than
> just
> >> a

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 06 Apr 2010 19:00:43 +0200

Hi all,

here at Deutsche Telekom, we see the need for a flow supporting the 
exchange of access tokens for one service into access tokens for another 
service.

The scenarios is as follows: In the context of mobile applications, we 
employ multi-layered architectures of personalized web services. The 
first layer typically exposes an API optimized for the flows of a 
particular application. This layer's business logic is built on top of 
other web services and so on. We use self-contained bearer tokens 
carrying id's, attributes and permissions. Each of the web services 
involed has a trust relationship with our authorization server based on 
shared secrets. Every web service requires a different token with 
different claims (id, permissions, attributes) and signature (HMAC).

The flow is as follows:

1) The client acquires a token for the first service eather by 
username/password authentication or web-based authorization flow.

2) The client sends a request (including the access token) to the first 
web service.

3) Access control and some business logic is executed based on the token 
contents. Afterwards, the first service determines that it needs
to call another services (second web service) on behalf of the user.

4) It requests the issuance of a new token for the second service from 
the authorization server based on the original token sent by the client.

5) The authorization server issues a new token carrying the claims need 
by the second web service and digitally signs the token
with the respective shared secret. It also encrypts the token content in 
order to prevent the first web service from eavesdropping the users data 
intended for the second service only.

6) The first web service uses the token to invoke the second web service.

...

Does anyone else see the need for such a flow?

regards,
Torsten.

---

From: David Recordon <[email-masked]>
Date: Tue, 6 Apr 2010 11:15:04 -0700

There is potential for leakage if the client then redirects the user to another SSL URL. This doesn't feel like a common pattern and the client would generally be redirecting to a page which they control after receiving the access token.

From 15.1.3 of RFC 2616:
Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.

On Apr 6, 2010, at 8:45 AM, Evan Gilbert <[email-masked]> wrote:

> Even with SSL, referrer leaks seem to be a danger (I think https referrers are still sent). Are we worried about this?
>  
> 
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 6 Apr 2010 14:44:27 -0700

On 4/6/10 7:04 AM, "Evan Gilbert" <[email-masked]> wrote:

>>> web

That's one way. A more developed proposal is another.

EHL

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 6 Apr 2010 15:39:44 -0700

On Tue, Apr 6, 2010 at 10:00 AM, Torsten Lodderstedt
<[email-masked]> wrote:
> Hi all,
>
> here at Deutsche Telekom, we see the need for a flow supporting the exchange
> of access tokens for one service into access tokens for another service.
>
> employ multi-layered architectures of personalized web services. The first
> layer typically exposes an API optimized for the flows of a particular
> application. This layer's business logic is built on top of other web
> services and so on. We use self-contained bearer tokens carrying id's,
> attributes and permissions. Each of the web services involed has a trust
> relationship with our authorization server based on shared secrets. Every
> web service requires a different token with different claims (id,
> permissions, attributes) and signature (HMAC).
>
> The flow is as follows:
>
> 2) The client sends a request (including the access token) to the first web
> service.
>
> 4) It requests the issuance of a new token for the second service from the
> authorization server based on the original token sent by the client.
>
> 5) The authorization server issues a new token carrying the claims need by
> the second web service and digitally signs the token

I think I suggested something like that on the scope thread:
"Things can get even more complicated. When the user grants access for
the client, the approval page should list all the scopes the client is
requesting. This is the set of scopes needed by the client for *all*
the API calls. Each API will need a subset of this approved, larger
set.

With that in mind, it would be useful to be able to down-scope access
tokens when using the refresh token, this way the client can send the
smallest set of scopes with each API call."

In your example, instead of having the first service request a new
token for the second service, step 4, I think the client should do
that and pass the second token as an argument in the API call.

Basically the client requests a refresh token with largest set of
permissions and then it uses the refresh token flow to get
lower-permission access tokens as needed.

The first service can ask for a second token only if the set of
permissions is a sub-set of the one it received, otherwise it has not
authority to do that.

Marius

---

From: Evan Gilbert <[email-masked]>
Date: Tue, 6 Apr 2010 17:24:48 -0700

On Tue, Apr 6, 2010 at 2:44 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> just a

Hah, ok :)

Can you give more feedback about what kind of information would help
clarify? Te exact meaning of the username needs to be tied to some identity
system (similiar to the username + password profile), and I wasn't sure how
to expand upon it.

Proposal:
In 2.4.1 & 2.4.2, add the following OPTIONAL parameter
username
  The resource owner's username. The authorization server MUST only send
back refresh tokens or access tokens for the user identified by username.

---

From: Brian Eaton <[email-masked]>
Date: Tue, 6 Apr 2010 22:13:41 -0700

On Tue, Apr 6, 2010 at 11:15 AM, David Recordon <[email-masked]> wrote:
> There is potential for leakage if the client then redirects the user to
> another SSL URL. This doesn't feel like a common pattern and the client
> would generally be redirecting to a page which they control after receiving
> the access token.
> From 15.1.3 of RFC 2616:
> Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP
> request if the referring page was transferred with a secure protocol.

There are several ways tokens passed on URLs tend to leak.  I think I
listed them all in the security considerations. [1]

If the callback URL points to a page that links to third-party
content, the third-party content will get a copy of the URL, including
the access token, via the referer header.  Search for 'referer' in the
browsersec wiki [2] for the gory details.

If the callback URL is an open redirector, it might be tricked into
sending the access token to an untrusted third-party.

If the web server logs requests, the access token will end up in the
web server logs.

Passing the token on the fragment mitigates all of those risks.
Callback URL whitelisting is also important.  Time-limited access
tokens are a final layer of defense.

There are some intrinsic risks here - I'd like to make sure that we
treat lightweight javascript clients (no secrets, transient data
access, authenticated only by callback URL) different than
full-fledged web servers (can keep secrets, permanent data access.)

Note that it's pretty easy for a web server to pass an access token
down into a javascript widget.  So I think there's a clear upgrade
path from the one mode to the other.

Cheers,
Brian

[1] http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations
[2] http://code.google.com/p/browsersec/wiki/Part1#Hypertext_Transfer_Protocol

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 6 Apr 2010 23:07:24 -0700

On 4/6/10 5:24 PM, "Evan Gilbert" <[email-masked]> wrote:

> refresh tokens or access tokens for the user identified by username.

What are the security implications? How can the client know that the token
it got is really for that user?

EHL

---

From: Evan Gilbert <[email-masked]>
Date: Tue, 6 Apr 2010 23:14:43 -0700

> it got is really for that user?

Think the client has to trust the auth server, in the same way as with the
username + password profile. The auth server can always send back a scope
for a different user.

Worst case is that there is an identity mismatch between client and the
identity implicit in the authorization token. This mismatch is already
possible, and I don't think the username parameter makes the problem worse.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 7 Apr 2010 00:08:22 -0700

What about an attacker changing the username similar to the way a callback can be changed?

EHL

On 4/6/10 11:14 PM, "Evan Gilbert" <[email-masked]> wrote:

On Tue, Apr 6, 2010 at 11:07 PM, Eran Hammer-Lahav <[email-masked]> wrote:

Think the client has to trust the auth server, in the same way as with the username + password profile. The auth server can always send back a scope for a different user.

Worst case is that there is an identity mismatch between client and the identity implicit in the authorization token. This mismatch is already possible, and I don't think the username parameter makes the problem worse.

EHL

---

From: Evan Gilbert <[email-masked]>
Date: Wed, 7 Apr 2010 08:22:35 -0700

>  What about an attacker changing the username similar to the way a

I don't think there is a danger here.

We still use all of the safeguards in place from the rest of the flow -
adding this parameter never log you in when omitting the parameter would not
have. It will just create more error responses.

---

From: John Panzer <[email-masked]>
Date: Wed, 7 Apr 2010 09:29:18 -0700

I'm assuming that tokens need not be bound to a specific user (typically
they are, but imagine a secretary granting an app access to his boss's
calendar and then leaving the company and therefore being removed from the
calendar ACL, but the app still keeping access by virtue of the capability
granted by the token).  In this case, the proposed wording seems kind of
problematic for a MUST.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 07 Apr 2010 20:34:30 +0200

Hi Marius,

> smallest set of scopes with each API call."

The idea of acquiring downsized access tokens is very interesting from a 
security standpoint. A client could obtain a token with the least 
privileges set required for the transaction it is about to perform thus 
reducing the impact if a token gets revealed.
> that and pass the second token as an argument in the API call.

You are right, this is an alternative option. We don't go that way 
because we don't want the clients to know the internal structure of our 
services. Therefore the first service (or any other service in the call 
chain) is exchanging the tokens. This token exhange is more a technical 
"claim transformation" than a scope reduction/transformation. As I 
described, trust between authz server and service ist based on shared 
secrets (as in Kerberos) so any piece data intended for a particular 
service must be encrypted/HMACd with the corresponding secret. Moreover 
(and most important), the token payload is different. That's why we 
can't use the same token for the whole call chain.
> permissions is a sub-set of the one it received, otherwise it has not
That's true.

regards,
Torsten.

---

From: Evan Gilbert <[email-masked]>
Date: Wed, 7 Apr 2010 22:46:18 -0700

> granted by the token).  In this case, the proposed wording seems kind of

Note that the "resource owner" in this case is the secretary, not his boss.
Resource owner is "An entity capable of granting access to a protected
resource."

Since access tokens are bound to the resource owner ("A unique identifier
used by the client to make authenticated requests on behalf of the resource
owner."), I think in this case the system would have a clear way to revoke
access to the document.

Updating the wording on the proposal slightly to clarify (also changing
format to new parameter formatting)

Before:
username
  The resource owner's username. The authorization server MUST only send
back refresh tokens or access tokens for the user identified by username

Current:
username
  OPTIONAL. The resource owner's username. The authorization server MUST
only send back refresh tokens or access tokens *capable of making requests
on behalf of* the user identified by username

>>> Think the client has to trust the auth server, in the same way as with
>>> the username + password profile. The auth server can always send back a
>>> scope for a different user.
>>>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 7 Apr 2010 23:21:24 -0700

I will leave this to the security folks to decide but it seems to me that if
the client asks to limit the username of the end user granting access by
specifying it in the request, the server must repeat that information when
issuing such a token. Otherwise, an attacker can force a user to grant
access to another account (for example, if they have both a personal and
work accounts on the same server) without the client being able to detect
it.

In other words, if the client can demand an access token for a specific
username, it should be able to have the absolute confidence (assuming it
trusts the server) that the access token received has that attribute.

EHL

On 4/7/10 10:46 PM, "Evan Gilbert" <[email-masked]> wrote:

>> I'm assuming that tokens need not be bound to a specific user (typically they
>> are, but imagine a secretary granting an app access to his boss's calendar
>> and then leaving the company and therefore being removed from the calendar
>> ACL, but the app still keeping access by virtue of the capability granted by
>> the token).  In this case, the proposed wording seems kind of problematic for
>> a MUST.
> 
> Since access tokens are bound to the resource owner ("A unique identifier used
> by the client to make authenticated requests on behalf of the resource
> Updating the wording on the proposal slightly to clarify (also changing format
> to new parameter formatting)
> 
> Before:
> username
> refresh tokens or access tokens for the user identified by username
> 
> Current:
> username
>   OPTIONAL. The resource owner's username. The authorization server MUST only
> send back refresh tokens or access tokens capable of making requests on behalf
> of the user identified by username
>  
>> 
>>>> On 4/6/10 11:14 PM, "Evan Gilbert" <[email-masked]
>>>> <http://[email-masked]> > wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> On Tue, Apr 6, 2010 at 11:07 PM, Eran Hammer-Lahav <[email-masked]
>>>>> <http://[email-masked]> > wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 4/6/10 5:24 PM, "Evan Gilbert" <[email-masked]
>>>>>> <http://[email-masked]> > wrote:
>>>>>> 
>>>>>>> Proposal:

---

From: John Panzer <[email-masked]>
Date: Wed, 7 Apr 2010 23:40:54 -0700

On Wed, Apr 7, 2010 at 10:46 PM, Evan Gilbert <[email-masked]> wrote:

> used by the client to make authenticated requests on behalf of the
> resource owner."), I think in this case the system would have a clear way to
> revoke access to the document.
>

Sorry, I was unclear.  In the scenario I'm imagining, the boss has delegated
calendar access to his secretary, who uses this delegated access to hook up
an app to the calendar.  The boss is very happy with this situation because
now his Zombieville reminders show up on his calendar.  If the token is tied
to the secretary, and the secretary's account is shut down when the
secretary leaves, then the boss no longer sees the Zombieville reminders pop
up.  He then complains that this sort of thing never happened with
password-based access!

I can imagine either scenario upon termination of the secretary -- you may
want to revoke all the tokens, some of the tokens, or none of the tokens.

---

From: Evan Gilbert <[email-masked]>
Date: Thu, 8 Apr 2010 08:31:13 -0700

On Wed, Apr 7, 2010 at 11:40 PM, John Panzer <[email-masked]> wrote:

>> Note that the "resource owner" in this case is the secretary, not his
>> boss. Resource owner is "An entity capable of granting access to a protected
>> resource."
>>
> Sorry, I was unclear.  In the scenario I'm imagining, the boss has
> delegated calendar access to his secretary, who uses this delegated access
> to hook up an app to the calendar.  The boss is very happy with this
> situation because now his Zombieville reminders show up on his calendar.  If
> the token is tied to the secretary, and the secretary's account is shut down
> when the secretary leaves, then the boss no longer sees the Zombieville
> reminders pop up.  He then complains that this sort of thing never happened
> with password-based access!
>

This seems to be an issue with all of the delegation profiles, and not
related to the username parameter.

Note that expected behavior in this case is unclear. If the secretary has
installed an app on her cell phone to view his boss' calendar, you clearly
do want to revoke access.

>> only send back refresh tokens or access tokens *capable of making
>> requests on behalf of* the user identified by username
>>
>>
>>>
>>>> On Wed, Apr 7, 2010 at 12:08 AM, Eran Hammer-Lahav <[email-masked]
>>>> > wrote:
>>>>

---

From: Evan Gilbert <[email-masked]>
Date: Thu, 8 Apr 2010 08:33:30 -0700

> trusts the server) that the access token received has that attribute.

Note: I'm fine with adding a username in the response if it helps from the
security side. It's not clear to me that there's a security hole, but it
never hurts to provide more information in the response back.

> they
> boss.
> used
> only
> >>> On Wed, Apr 7, 2010 at 12:08 AM, Eran Hammer-Lahav <
> [email-masked]>
> >>> wrote:
> >>>> What about an attacker changing the username similar to the way a
> callback
> >>>> can be changed?
> >>>

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Thu, 8 Apr 2010 16:24:34 -0500

Torsten,

I really like this use case. I think it ought to be documented on its own.  (But please let me know if you disagree and thing that it is a subset of another use case.)

I also see potential synergy with the recursive delegation case. 

For my use-cases draft, I am trying to develop a common template for all use cases.  In a day or two, I am going to send your case described in this template to check your opinion.

Zachary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Torsten Lodderstedt
Sent: Tuesday, April 06, 2010 1:01 PM
To: [email-masked]
Subject: [OAUTH-WG] Access Token Exchange Flow

Hi all,

The flow is as follows:

...

regards,
Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 10 Apr 2010 08:59:46 +0200

Hi Zachary,

that's fine with me.

regards,
Torsten.