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).
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.
With the additional aspects (OAuth 2 refresh token returned, OAuth 1
access token revoked), the flow might only be performed once?
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.
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.
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.
Am 08.07.2010 20:26, schrieb Marius Scurtescu:
The bridge flow was meant to be used in a mixed OAuth 1 and OAuth 2
environment, it allows the consumer to obtain a token using signatures
and then access protected resources with no signatures. Now that
signatures are re-introduced in OAuth 2 I don't think there is a need
for such an approach.
That being said, migration can be done very similarly, differences
from the bridge flow:
- an OAuth 2 refresh token is also returned
- optionally the OAuth 1 token is revoked
Such a migration flow would allow a consumer/client that has OAuth 1
access tokens saved for its users to convert all of them to OAuth 2
refresh tokens without involving the users.
Marius
On Thu, Jul 8, 2010 at 4:05 AM, Stefanie Dronia<sdro...@gmx.de> wrote:
Hi,
I took a look at the OAuth 1 Bridge Flow suggested by Marius, the thread
"OAuth 1 Bridge Flow" and had some thoughts:
I do not really see the necessity for such a flow.
First of all, all participating parties have to be modified and rolled out:
- the consumer's application to support (at least) the bridge flow (and
OAuth 2 [1]),
- the authz server to provide OAuth 2 and additionally the bridge flow and
- the resource server to handle OAuth2.
Then, sometime later, when at least the authz server doesn't support OAuth 1
anymore, the client application and the resource server should be cleared up
- no more OAuth 1, only OAuth 2. Again a new version to roll out.
The only (small) benefit I see, is that the user will not be asked for
authorization again.
But is it worth it to develop, implement and roll out a Bridge Flow? I do
not think so - too much expense for a small user interaction.
Better: directly go to OAuth 2, when it is needed.
The other thing I'm missing, is how to migrate completely to OAuth 2 after
performing the bridge flow. Issuing a refresh token in the response seems
necessary. But this issue was still mentioned (but not solved) in the thread
"OAuth 1 Bridge Flow" by Eran.
Thanks,
Steffi
[1] if OAuth 2 will not be supported, a new modified client has to be rolled
out at the latest, the resource server doesn't support OAuth 1 anymore.
-------- Original-Nachricht --------
Datum: Tue, 6 Jul 2010 21:54:16 -0700
Von: Marius Scurtescu<mscurte...@google.com>
An: Rob Richards<rricha...@cdatazone.org>
CC: "oauth@ietf.org"<oauth@ietf.org>
Betreff: Re: [OAUTH-WG] Versioning
On Sat, Jul 3, 2010 at 3:27 AM, Rob Richards<rricha...@cdatazone.org>
wrote:
Eran Hammer-Lahav wrote:
Hi Rob,
I agree with you that a migration spec is important - please write one.
Like I didn't see that coming :)
I would like to help with this migration spec. Is this a good starting
point:
http://www.ietf.org/mail-archive/web/oauth/current/msg02300.html
Or, you had something else in mind?
Marius
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
