Subject: [OAUTH-WG] implicit clients and refresh tokens

From: Doug Tangren <[email-masked]>
Date: Thu, 21 Apr 2011 12:26:14 -0400

According to
http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-4.2.2 it doesn't
look like clients of the implicit oauth2 flow should receive a refreshing
token although it looks like the access token can optionally have an
expires_in time set. Does this mean there is no step for an implicit client
to refresh their access token without involving the user again?

According to http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-6 it
looks like a client needs to send in the client credentials, including the
client secret, to refresh an access token. This is a no-go for clients that
can't securely secure a client secret like a web browser.

Is providing no way for an implicit client to refresh an access token
without involving the resource owner intended?

-Doug Tangren
http://lessis.me

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 21 Apr 2011 09:34:32 -0700

Yep.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Doug Tangren
Sent: Thursday, April 21, 2011 9:26 AM
To: [email-masked]
Subject: [OAUTH-WG] implicit clients and refresh tokens

According to http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-4.2.2 it doesn't look like clients of the implicit oauth2 flow should receive a refreshing token although it looks like the access token can optionally have an expires_in time set. Does this mean there is no step for an implicit client to refresh their access token without involving the user again?

According to http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-6 it looks like a client needs to send in the client credentials, including the client secret, to refresh an access token. This is a no-go for clients that can't securely secure a client secret like a web browser.

Is providing no way for an implicit client to refresh an access token without involving the resource owner intended?

-Doug Tangren
http://lessis.me

---

From: [email-masked]
Date: Thu, 21 Apr 2011 16:40:53 +0000

What app do you intend to implement? It could use the authorization code flow in order to also obtain refresh tokens.  Authorization servers may also support token refreshment for clients w/o secrets.

Regards,
Torsten.
Gesendet mit BlackBerry® Webmail von Telekom Deutschland  

-----Original Message-----
From: Eran Hammer-Lahav <[email-masked]>
Sender: [email-masked]
Date: Thu, 21 Apr 2011 09:34:32 
To: Doug Tangren<[email-masked]>; [email-masked]<[email-masked]>
Subject: Re: [OAUTH-WG] implicit clients and refresh tokens

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

---

From: Doug Tangren <[email-masked]>
Date: Thu, 21 Apr 2011 14:22:07 -0400

I was thinking for something purely browser based, akin to facebook connect
or twitter anywhere, where the client would only have to ask the user for
authorization once. I don't know what the current practice is for storing an
access token is client side (cookie/local storage), but regardless, either
every time the user refreshes the page or access token expires, the client
would have to ask the user again for authorization. Even if the user didn't
revoke access.

Is there a current practice for how an implicit client should store access
tokens or if they should store them at all?

Also what is the current state of which token type to implement for access
to protected resources? I've heard a few arguments for and against both
bearer and mac but for many oauth2 implementers, it seems the current
practice is to use neither and just append the access_token to a client
request. I see an understand the danger is in this if an access token were
leaked so I am making sure to implement expiring tokens. I just wasn't sure
if this was in the cards for clients implementing an implicit flow.

Thanks for responding so quickly guys.

-Doug Tangren
http://lessis.me

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 29 Apr 2011 15:18:23 -0700

On Thu, Apr 21, 2011 at 9:26 AM, Doug Tangren <[email-masked]> wrote:
> According to http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-4.2.2
> it doesn't look like clients of the implicit oauth2 flow should receive a
> refreshing token although it looks like the access token can optionally have
> an expires_in time set. Does this mean there is no step for an implicit
> client to refresh their access token without involving the user again?
>

This is a real issue and the only solution I am aware of is to support
an immediate mode and auto-approvals. When the access token expires
the client can try an immediate mode request in an invisible iframe.
If it works, then it has a new access token, if not then it must
involve the user.

For immediate mode an extra parameter is needed, no defined in the
core spec, that tells the authorization server that no UI should be
shown and an auto-approval should be attempted. Google currently
supports this, the immediate mode parameter is immediate=true.
Auto-approval will happen if the same client/user/scopes/redirect_uri
have been approved before.

Hope this helps,
Marius

---

From: "Richer, Justin P." <[email-masked]>
Date: Sat, 30 Apr 2011 15:13:44 -0400

Seems like immediate mode should be added into the UX spec to me, maybe even as "display=none". Is there any interest in that?

 -- Justin
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Marius Scurtescu [[email-masked]]
Sent: Friday, April 29, 2011 6:18 PM
To: Doug Tangren
Cc: [email-masked]
Subject: Re: [OAUTH-WG] implicit clients and refresh tokens

Hope this helps,
Marius