See comments bellow...
On Fri, Jul 9, 2010 at 4:27 AM, Stefanie Dronia <sdro...@gmx.de> wrote: > Hallo Marius, > > thanks for your statement. > Your idea of a migration flow is quite good and necessary. > > But I still doubt, if the work and effort should be investigated to spare > the user from some interaction (authentication and user consent). It all depends for how many users does the client have OAuth 1 tokens. Asking users to re-approve will confuse them and I guess many will not do it, > Latest he will be asked for his consent at the time, the refresh token > expired (as long as the refresh token has a limited validity period [1]) and > a new one is requested. That's authz implementation specific, but in most cases I think refresh tokens (or OAuth 1 access tokens) never expire. > With the additional aspects (OAuth 2 refresh token returned, OAuth 1 access > token revoked), the flow might only be performed once? Yes, I see this as a one time migration. > By the way, the revoke of the OAuth 1 token should not be optionally, but a > must IMO. By that way, the consumer is enforced to process with OAuth 2 > flows. Yes, the consumer has to switch over to OAuth 2. > > Have a nice weekend! > Steffi > > [1] That a refresh token has a limited validity period is not defined in the > spec. But the authz server should be able to invalidate it. It sure does. Also, I assume that most authz servers will give this option to the end user, some page where they can see all the refresh tokens issued for them and where they can revoke them. > E.g. when the refresh token is issued, a long, but limited validity period > is assigned to it. Each time, new access token(s) are requested with the > refresh token as access grant, the refresh token's validity period is > extended. If not, it gets invalid reaching the assigned limit. This flow > represents the user's usage of the consumers application. (Quasi) Infinitely > valid refresh token at continuous usage of the consumers application. > Limited validity at rare or no usage, Revocation of the granted access is > done automatically w/o user intervention. An interesting idea. I guess it is up to the authz server to implement something like this. Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
