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