OAuth JWT and JWK limits

[ngerakines]

OAuth looks good so far, but I have a couple of questions regarding practical limits on the number of JWTs and JWKs.

In the context of generating OAuth requests, is state validated as globally unique, and is that forever or just at any given time? For example, an oauth_request with state=foo1 is sent and concludes successfully; later, if another request with state=foo1 is used, are previous states purged so that the later use of foo1 will succeed?

For DPOP, are handle JWKs meant to be recycled? For example, if a user goes through the OAuth session creation process and a JWK is created for the user to create proofs, later, if the user creates a new session (like on a different device), is the same DPOP JWK meant to be reused but with a different nonce?

I don't see anything that shows when DPOPs expire server-side. If DPOP JWKs are meant to be long-lived and span multiple sessions, is there a way to either set a hint (i.e. Smoke Signal will use this DPOP JWK for at most 28 days) or get a ttyl value from the server?

On the other hand, if DPOPs are not long-lived and expire when the aggregate sessions for any access tokens associated with refresh tokens expire, can that be confirmed?

Do DPoP nonces expire deterministically, and is there a way to request a nonce with a signed request if we know one is expired without implementing retry mechanics? The current limitation with DPoP nonces is that they force all requests to be serial because there's no guarantee that any given request will be rejected due to a new nonce being needed, and if that value does change, any other future requests need to rely on it. If that were time-boxed or if the nonce was counter based, it'd at least give implementations a way of knowing that the Nth request or after N seconds a new nonce would need to be used.

[ngerakines]

From the spec:

In addition to being bound to the client's DPoP key, all tokens issued by the AS will also be bound to the public key used by the client to authenticate itself through the urn:ietf:params:oauth:grant-type:jwt-bearer grant (only for public client). If, at any point, a client stops advertising a public key that is used in active sessions, all those sessions will be invalidated. The AS will choose, at its discretion how it will implement this (proactively, whenever metadata are fetched, on the next token refresh, etc.).

This isn't entirely clear. Is it saying that the PDS is creating an association between the provided DPoP JWKs and access_tokens with the public keys listed by the client application (i.e., https://smokesignal.events/oauth/jwks.json )?

How flexible is that to server failure? Like, if those JWKs are serviced by a content accelerator that has a delay in updating, so one region has kids 1, 2, and 3, while another region has kids 2, 3, and 4, does that mean that requests with the new key (4) could blip out if a refresh call accidentally gets the old set of 1, 2, and 3?

[matthieusieben]

Old keys should still be advertised in the jwks but no longer used to initiate new sessions. If a key is known to have been compromised, it must be removed from the jwks, effectively preventing it from being used to refresh sessions.

[ngerakines]

Yeah, I guess the specific question is how quickly will personal data servers mark keys as revoked if they don't appear once, or if requests for JWKs fail, etc.

[matthieusieben]

This is currently being discussed as part of a draft RFC
https://github.com/aaronpk/draft-parecki-oauth-client-id-metadata-document

Right now our stance is that this is left at the discretion of the pds implementation

[ngerakines]

From the spec:

Authenticated clients should rotate their keys on a regular basis (e.g. on every new app release, or every month, whichever comes first). They can do so by adding a new key to their JWKS and removing the old ones from time to time. If a breach is detected, the client must immediately remove the compromised key from its JWKS. If the mitigation of the breach takes long, all the keys must be removed from the JWKS as the issue is being fixed, preventing any new tokens from being issued.

Does the same hold true with DPoP keys? If DPoP keys are meant to be long-lived and recycled between handle sessions, should they be proactively expired after ~30 day window?

[matthieusieben]

The best, even from a backend server, is to use a distinct Dpop key per oauth sessions. The Dpop spec does not prevent keys generated on a device from being reused for other oauth sessions generated from the same device. We might make the Atproto spec more strict in that regard.

The real important thing here is that Dpop keys must never leave the device as the very purpose of dpop is to protect against tokens being stolen while "in transit".

[ngerakines]

Yeah, so a safe, practical data retention policy would be to purge DPoP JWKs based on the latest access_token associated with it.

Also, to confirm, when a DPoP JWK is used during the initial session creation and access_token minting process, the same DPoP JWK needs to be used with subsequent refresh_token and access_token calls, effectively prolonging the lifespan of that DPoP JWK. Does that sound right?

[matthieusieben]

Also, to confirm, when a DPoP JWK is used during the initial session creation and access_token minting process, the same DPoP JWK needs to be used with subsequent refresh_token and access_token calls, effectively prolonging the lifespan of that DPoP JWK. Does that sound right?

Yep

[matthieusieben]

In short: Dpop keys must never leave the device they were created on (whether it's a server or a end-user device). Ideally, one dpop key should be used for one, and only one, oauth session. The dpop key can be used for as long as the access/refresh tokens of the particular oauth session the drop key was bound to are valid. There is no mechanism to rotate the dpop key bound to a pair of tokens other than initiating a new oauth flow to retrieve new tokens. Oauth servers should prevent the same dpop key to be used, in particular when the client is not a confidential client.

As for the dpop nonces: they stay valid (and identical for every user) for a short period of time. When a new nonce is created on the server, the previously advertised nonce can still be used for a short period of time. This means that the client can safely run multiple requests in parallel as long as a recent nonce is used (or they would all fail).

We will make sure to include these clarifications in the spec.

[ngerakines]

they stay valid (and identical for every user)

Makes sense. It sounds like it isn't actually per-DPoP or per-Handle locking, but really per-PDS locking then. With a DPoP Nonce being shared across all handles for a given PDS, the following is true:

1. Smoke Signal prepares to make an API call for did:plc:abcd1234 with Nonce foobar1
2. Smoke Signal prepares to make an API call for did:plc:efgh1234 with Nonce foobar1
3. Call did:plc:abcd1234 with Nonce foobar1 fails and server replies use Nonce foobar2
4. Call did:plc:efgh1234 will fail because it should be using Nonce foobar2.

We will make sure to include these clarifications in the spec.

Thanks. This makes a lot of sense to document the behavior of, but the takeaway is that these still should treated as ephemeral maybe time based random values. If a server restarts, even if it is "before" the nonce would normally be regenerated, that is a valid scenario where the newer value needs to be used, right?

[ngerakines]

Continuing that thought, is there a counter or expected upper limit for calls made with invalid / expired Nonce values? What I'm wondering is how "safe" do servers need to be with calls before some sort of action that would result in blocking the server takes place?

[matthieusieben]

If a server restarts, even if it is "before" the nonce would normally be regenerated, that is a valid scenario where the newer value needs to be used, right?

Our current pds implementation uses a predictable time based random number generator (based on a secret key) to avoid invalidating previous nonces upon restart. But our spec does not specify what strategy must be used by pds in that regard.

[matthieusieben]

Dpop nonces are only there to prevent an attacker from pre-generating a bunch of dpop proofs to be used at another moment in time.

I am not sure what measure should be taken if a pds starts seeing lots of invalid nonces. It would either indicate that an attacker tried to pre-generate dpop proofs or that a client implementation is faulty. The latter would probably be more likely.

[matthieusieben]

As for the "state", oauth does not prevent the state from being re-used. The oauth (oidc) "nonce" oauth request parameter (not to be confused with the Dpop nonce), however, must be unique to every oauth request.

That being said, there is a wide variety of attacks that involve manipulating the state. For that reason, it is recommended to store the actual state data on the device/server, and use a random value as oauth request parameter. Clients should invalidate the encoded state (= the random value) once it was used in order to prevent an attacker from forcing a user to re-authenticating using an old state.