On Wed, Jul 14, 2010 at 2:32 PM, Torsten Lodderstedt
<tors...@lodderstedt.net> wrote:
> We expected the clients to discard the old refresh token and to use the
> newly issued refresh token instead. The old refresh tokens is revoked
> instantly. Any attempt to use it afterwards is interpreted as a potential
> misuse because the assumption would be that an adversary has copied the
> token or cloned the device. The client should notify the user of the problem
> and recommend him/her to check its application authorizations (refresh
> tokens) in our user self care portal. There, the user will have acces to
> information on when the token has been used the last time and therewith
> detect any odd behavior. The user could then revoke the token and/or alarm
> its providers helpdesk.
My use cases for this are a little different.
1) I'm interested in the two-legged flows as well as three-legged flows.
For example, imagine an autonomous client that is registered once,
and then after that maintains its own key material. Regular rotation
of the key material is good cryptographic hygiene.
2) I'm interested in distributed scenarios.
For example, imagine a geographically distributed client
application, or a client application that is extremely busy. In both
these cases, you run into race conditions where refresh tokens are
changed even as they are being used.
3) I'm interested in authentication besides bearer tokens, in
particular public keys used to verify assertions.
4) I'm less interested in installed applications.
I understand your use case for rotating refresh tokens, but it's
somewhat less important for me.
That said, maybe we could arrive at a set of protocol flows that we
would both implement the same way, and would meet all of those use
cases? For example, would a protocol where the client secret for
installed applications changed regularly work for you?
Maybe something like this:
- when a client contacts the authorization server, it would provide a
hint that it supports key rotation
- the authorization server may return an error code that says "key
rotation needed"
- the client would then generate a new secret key (this could be
either a machine-generated password, or an HMAC key, or a
public/private key pair.)
- the client would then contact the authorization server again,
signing the message with the old key, and providing the verification
material for the new key.
- the authorization server would then store the new key, and mark the
old key for expiration.
- subsequent requests from the client would be signed with the new key
Note that in the case of installed applications using the
user-approval flows, you would associate the new key material with the
client-id and refresh token together, rather than the client-id alone.
Otherwise it's impossible to look up the verification material for
requests, since you would quickly run into problems with a single
client-id mapping to zillions of secrets.
Cheers,
Brian
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
