Re: [OAUTH-WG] Refresh tokens

1&2) Yep.  This is why flows using Refresh Tokens must always use SSL.

3) Refresh tokens are comparable to access tokens in that you can scope them etc.  In fact it makes a great deal of sense to limit them in the same way the access tokens are limited.

4) The answer here depends on the security requirements for your app.  It all depends on whether you feel the client can keep a secret, either a MAC signing secret or a token.  Whether you store them on disk or not depends a lot on how you'd plan to store them, if it's in a browser then you're pretty much trusting the user level file security on the computer.

5) Not sure, might be that Eran wanted to generalize it so as not to be putting specific authentication scheme constructs into the base framework.

-bill

________________________________
 From: Bart Wiegmans <bart@all4students.nl>
To: oauth WG <oauth@ietf.org> 
Sent: Monday, November 28, 2011 7:20 AM
Subject: Re: [OAUTH-WG] Refresh tokens

I forgot the following question:

5. If refresh taken are just another way of requesting access tokens, I
believe they should be specified in section 4, with other grant types.
But there must be a reason for the way it is now, so why?

With kind regards,
Bart Wiegmans | Developer

-----Oorspronkelijk bericht-----
Van: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] Namens Bart
Wiegmans
Verzonden: maandag 28 november 2011 16:13
Aan: oauth WG
Onderwerp: [OAUTH-WG] Refresh tokens

Hello everybody,

This is my first post on this mailing list, so I will introduce myself.
My name is Bart Wiegmans, I work in Groningen, the Netherlands. I am
involved with OAuth2 because I am implementing an authorization server
for my employer, all4students / studenten.net.

I have few remarks about refresh tokens.

1. The way I understand it, they are a way to limit the impact of access
token exposure. Which I find desirable.
2. However, they can also be seen as credentials for an access token
request. In which case, refresh token exposure is a more serious risk
than access token exposure.
3. Are there, or will there ever be, multiple refresh token types as
there are access token types?
4. Can a public client use refresh tokens at all, or is this
meaningless? If not, are public clients that are installed on a users'
computer or smartphone required to re-authorise every time an access
token expires? (This would be undesirable). Should they request
long-lived access tokens? 

About MAC tokens, I wonder about the practicality of public (javascript)
clients using them as a token type. 

With kind regards,
Bart Wiegmans | Developer
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth