Re: [OAUTH-WG] issuing new refresh tokens

[Torsten Lodderstedt <[e-mail]>]

Am 15.07.2010 07:14, schrieb Brian Eaton:
> ...
> 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.
>    

How is the client registered? Out of band or via API?

> 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.
>    

What is the difference between rotating a key and changing the refresh 
token with respect to such race conditions?

> 3) I'm interested in authentication besides bearer tokens, in
> particular public keys used to verify assertions.
>    

Authentication between which parties? client and authz server, client 
and resource server?

> 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?
>    

Why not? Let's talk about :-)

The following comments are given with focus on installed application.

> Maybe something like this:
>
> - when a client contacts the authorization server, it would provide a
> hint that it supports key rotation
>    

where would the initial secret come from? Would it be the same secret 
for all installations? I assume there is no initial secret and key 
material is used to protect the refresh tokens only. It is not used to 
authenticate the client.

> - 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.)
>    

I would prefer if the authz server would issue the fresh secrets (at 
least for shared secrets).

> - 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.
>    

when will the old key expire? Instantly?

> - 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.
>    

what about clients with multiple refresh tokens from the same authz 
server? Would they need different secrets? Or would you suggest to 
associate all refresh tokens with the respective key material?

I would rather suggest the following approach:

We distinguish clients (application type) and client instances 
(installation).
Every installed application is registered with the authz server as a 
separate client instance (identified by an new client_id). As far as I 
remember, there has been a proposal on the list to introduce instance 
identifiers recently.
Key material is managed per client instance. Refresh tokens are assigned 
to a particular client instance.

That way an authz server can identify and lock out particular 
installations (e.g. the media center app on my iPhone). The same holds 
for end-users, a self care UI could vizualize different installations 
and their authorizations. If the authz server also manages the relation 
between clients and client instances, a particular application can be 
black listed, too.

Bottom line: it's an viable alternative to rotate keys instead of 
issuing new refresh tokens. In my opinion, this is the more complex way 
to protected installed applications because it requires a client 
registration and key rotation protocol. On the other hand, (in 
combination with instances) it has some additional advantages.

What is your assessment?

regards,
Torsten.

> Cheers,
> Brian
>    

Assumptions

in the case of installed applications, the secret is used to protect 
refresh tokens only
no client authentication