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: [email protected] [mailto:[email protected]] 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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to