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