Subject: [OAUTH-WG] User-Agent flow and refresh tokens

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 15 Sep 2010 23:47:15 +0200

I'm wondering whether it makes sense to allow for the issuance of 
refresh tokens by the user-agent flow.

Background of my considerations is the development of applications on 
mobile devices (apps :-)). The draft suggests to either use the web 
server or the user agent flow for the integration of such applications 
with an OAuth authorization server. For sake of user experience, I would 
expect mobile applications to use refresh tokens instead of sending the 
user through the authorization on every application start. I also would 
assume that the mobile client does not use a client secret because it 
cannot really protect it from recovery. Instead, token theft could be 
encountered by replacing refresh tokens with every request to the tokens 
endpoint.

This scenario is feasable with the web server flow but not with the 
user-agent flow. This is because the later does only support the 
issuance of access tokens. In previous discussions this has been 
motivated by the weaker security (missing client authentication) of the 
user-agent flow. But as pointed out above, the web server flow can (and 
will be) used w/o client secret, too.

So why don't we allow for the  issuance of refresh tokens by the 
user-agent flow?

regards,
Torsten.

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 15 Sep 2010 15:25:07 -0700

I don't see why would you use the user-agent flow with a native
application? Maybe the spec should suggest only the web server flow.
The device flow would also work, but that's not part of the core spec.

Marius

On Wed, Sep 15, 2010 at 2:47 PM, Torsten Lodderstedt
<[email-masked]> wrote:
>  I'm wondering whether it makes sense to allow for the issuance of refresh
> tokens by the user-agent flow.
>
> Background of my considerations is the development of applications on mobile
> devices (apps :-)). The draft suggests to either use the web server or the
> user agent flow for the integration of such applications with an OAuth
> authorization server. For sake of user experience, I would expect mobile
> applications to use refresh tokens instead of sending the user through the
> authorization on every application start. I also would assume that the
> mobile client does not use a client secret because it cannot really protect
> it from recovery. Instead, token theft could be encountered by replacing
> refresh tokens with every request to the tokens endpoint.
>
> user-agent flow. This is because the later does only support the issuance of
> access tokens. In previous discussions this has been motivated by the weaker
> security (missing client authentication) of the user-agent flow. But as
> pointed out above, the web server flow can (and will be) used w/o client
> secret, too.
>
> So why don't we allow for the  issuance of refresh tokens by the user-agent
> flow?
>
> regards,
> Torsten.
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Andrew Arnott <[email-masked]>
Date: Wed, 15 Sep 2010 20:53:27 -0700

The user agent flow works for native apps that can host a web browser.  It
works pretty well in my experience.

Secrets on native apps are good!  The key is (no pun intended) that the
secret *not ship with the app*.  Each client should register for its own
client_id and secret when it is installed on the client machine.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre

On Wed, Sep 15, 2010 at 3:25 PM, Marius Scurtescu <[email-masked]>wrote:

> mobile
> user-agent

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 16 Sep 2010 07:39:14 +0200

Am 16.09.2010 um 05:53 schrieb Andrew Arnott <[email-masked]>:

> The user agent flow works for native apps that can host a web browser.  It works pretty well in my experience.
> 
Would like to see support for refresh tokens in this flow?
> Secrets on native apps are good!  The key is (no pun intended) that the secret not ship with the app.  Each client should register for its own client_id and secret when it is installed on the client machine. 
> 
Yes, native apps can obtain a key when they are installed on a device (Not part of the core). What does it help with respect to the Client authentication? 

Regards,
Torsten.

> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
> 
> 
> 
> On Wed, Sep 15, 2010 at 3:25 PM, Marius Scurtescu <[email-masked]> wrote:

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 16 Sep 2010 09:04:19 -0700

> Would like to see support for refresh tokens in this flow?

Sure, User-Agent works for native apps, but why would you use this
flow over web server?

In other words, why add refresh tokens to user-agent when you can use
web server?

Thanks,
Marius

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 16 Sep 2010 21:00:23 +0200

I don't know whether I understand you correctly. Are you saying that refresh tokens only make sense in Web servers?

regards,
Torsten.

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 16 Sep 2010 12:35:57 -0700

> I don't know whether I understand you correctly. Are you saying that refresh tokens only make sense in Web servers?

I was referring to the "web server" flow/profile. Not web servers in general.

Why would a native app use the user-agent flow (response_type=token)
over the web server flow (response_type=code)?

Marius

---

From: Kris Selden <[email-masked]>
Date: Fri, 17 Sep 2010 16:28:56 -0700

> Secrets on native apps are good!  The key is (no pun intended) that the secret not ship with the app.  Each client should register for its own client_id and secret when it is installed on the clien…

Maybe I'm missing something but...

If it has no credentials, why does sending it credentials after it has been installed, prove the client app is trusted?  Isn't an installed app without credentials, an untrusted app?  How do you know when you register the client that it is the app you think it is?

What can the client you want to register do that a client you don't want to register can't after install?

How would say an iPhone client that I download register?  Push notifications?  What if the end user hasn't enabled them? (I know a lot of people who turn them off) Also, if they've been hacked on a jailbroken phone (http://www.pushfix.info) are they really proving that the client is the client you think it is?

"The specification is very clear (as the article quotes) – don’t use client secrets in installed applications! The reason why the specification doesn’t say much more is because there is no solution. It does not exist for a distributed application unless you issue a different secret to each installation."
http://hueniverse.com/2010/09/all-this-twitter-oauth-security-nonsense/

Once the secret is installed isn't it still vulnerable after installation? Or is it because you can revoke the one abused secret (after detecting that it has been abused) without invalidating all the installed clients.

It seems like what would be ideal is if these mobile app marketplaces could install a unique client secret when an app is purchased. Otherwise I would think an untrusted app could just mimic a trusted app during registration.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 19 Sep 2010 16:29:10 +0200

> over the web server flow (response_type=code)?

The draft mentions both options 
(http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-1.4.3) and 
also states:

"Embedded user-agents often offer a better end-user flow, as they remove 
the need to switch context and open new windows."

Luke Shepard also indicated in his posting 
http://www.ietf.org/mail-archive/web/oauth/current/msg03509.html that 
facebook supports the user agent flow for desktop applications. 
Facebook's iOS SDK seems to use the same technique for mobile apps.

regards,
Torsten.

> Marius
>
>> regards,
>> Torsten.
>>
>>
>>
>> Am 16.09.2010 um 18:04 schrieb Marius Scurtescu<[email-masked]>:
>>
>>>> Am 16.09.2010 um 05:53 schrieb Andrew Arnott<[email-masked]>:
>>>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 19 Sep 2010 16:37:00 +0200

> It seems like what would be ideal is if these mobile app marketplaces could install a unique client secret when an app is purchased. Otherwise I would think an untrusted app could just mimic a trus…

that's a very interesting idea but it requires a strong trust 
relationship between app marketplace and authorization server.

In my opinion, client secrets dynamically issued by the OAuth 
authorization server might at most be a solution against session 
fixation attacks (cf. 
http://www.ietf.org/mail-archive/web/oauth/current/msg04358.html).

regards,
Torsten.

---

From: Marius Scurtescu <[email-masked]>
Date: Sun, 19 Sep 2010 12:08:53 -0700

On Sun, Sep 19, 2010 at 7:29 AM, Torsten Lodderstedt
<[email-masked]> wrote:
>>> I don't know whether I understand you correctly. Are you saying that
>>> refresh tokens only make sense in Web servers?
>>
> (http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-1.4.3) and also
> states:
>
> "Embedded user-agents often offer a better end-user flow, as they remove the
> need to switch context and open new windows."

Embedded user-agent does not mean user-agent profile. The client can
embed the browser (aka user-agent) and then use either the web server
(response_type=code) or the user-agent (response_type=toke) profiles.
"user-agent' is used in two totally different (and orthogonal)
contexts.

> facebook supports the user agent flow for desktop applications. Facebook's
> iOS SDK seems to use the same technique for mobile apps.

Yes, Facebook is recommending the User-Agent flow for desktop
applications. This works for them because access tokens issued by
Facebook are not short lived, I don't think they expire. The desktop
app does not need a refresh token.

If the authz server is issuing short lived access tokens and also
refresh tokens then the user-agent profile does not work so well
anymore. As far as I can tell in this case there is no reason to use
this profile with desktop apps, just use the web server profile.

Marius

---

From: Luke Shepard <[email-masked]>
Date: Mon, 20 Sep 2010 05:34:38 +0000

> this profile with desktop apps, just use the web server profile.

That's true. Although code_and_token is intended to solve that - you get the access token in the response, and then you can use the code to exchange for a refresh token on the server side if you need longer term access. There's no reason for a user agent to ever have a refresh token (since the performance optimization doesn't make sense when you are refreshing after an expiration period)

---

From: Kris Selden <[email-masked]>
Date: Mon, 20 Sep 2010 12:29:35 -0700

What is dynamic client registration?

I think it will be common to naively to use the password grant in a client app (like on a phone) when the company making the app is the same as the company who controls the auth server.

The question is whether there is really anyway to know if that client app is indeed your own app and not something mimicking it.  How does a dynamic client registration prevent an untrusted client from performing the same registration steps as your trusted client if your trusted client can't protect any secrets in the first place?  In other words what would authenticate a client during the registration?

Seems to me, if you allow password grant type even on your own client (which I suspect is going to be commonly desired), you are allowing any client to pretend to be yours and use this grant type.

It is then up to the end user to trust the client.  In the other flows, your server at least has a chance to give the user feedback on what the server thinks the client they are registering is.

If you are implying dynamic registering of the client (unspecified) as involving the end user to provide trust, isn't that already part of other flows?

I still get the sense that client secrets probably don't belong on iPhone apps and I shouldn't be using the password grant type unless I'm ok with any client using it.

Though I would love to be able to use that flow on our own iPhone app (because there is some pressure for this and a lack of understanding why we can't trust it is our own app which I suspect will be common as well).

On Sep 19, 2010, at 7:37 AM, Torsten Lodderstedt wrote:

> that's a very interesting idea but it requires a strong trust relationship between app marketplace and authorization server.
> 
> In my opinion, client secrets dynamically issued by the OAuth authorization server might at most be a solution against session fixation attacks (cf. http://www.ietf.org/mail-archive/web/oauth/current/msg04358.html).
> 
> regards,
> Torsten.
> 
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 21 Sep 2010 09:42:40 +0200

> That's true. Although code_and_token is intended to solve that - you get the access token in the response, and then you can use the code to exchange for a refresh token on the server side if you ne…

Sorry for being persistent, but I want to understand what the benefit of 
the user agent flow is. I'm assuming their is a benefit beyond 
supporting JavaScript clients. But this benefit is not really 
transparent to me. And by the way, that was one of the questions raised 
(and not completely answered) at IETF 78.

In my understanding of all the discussions on the list, the major 
difference to the web server flow is that the client does not need to 
have an active server side in order to obtain tokens, just a static 
responder page. Tokens are directly transfered on the (HTTPS protected) 
direct communication link to the authorization server, which also result 
in performance and load optimizations.

Why doesn't it make sense to obtain refresh tokens that way while it 
make sense to issue long-living access tokens?

Would you please comment?

regards,
Torsten.