Episode 204 - GluuFederation/identerati-office-hours GitHub Wiki

Title: OAuth Client Challenge Protocol

Channels

Description

OAuth assumes a client presents the right grant and gets a token. But what happens when the authorization server needs more proof mid-flight—an attestation, a verifiable presentation, or evidence that the client is authorized to perform a high-risk action? In this episode, we discuss the OAuth Client Challenge Protocol draft, a new proposal that enables dynamic, just-in-time authorization by allowing authorization servers to challenge clients for additional proof before issuing tokens.

Homework

Takeaways

  • ⚡ Long-running AI agent tasks may need more authority after the human is gone. Logically, if AI Agents initially obtain least privilege access tokens, it makes sense that they would need to up-scope (or even possibly down-scope) them later. This spec imagines that we make the OAuth token endpoint stateful, so the AS can interact with the OAuth client continuously.

  • ⚡ Replay protection is the hard part. Once the "challenge_session" reference identifier adds state, sender-constrained token binding would prevent replay. But what about public OAuth clients that can't protect secrets? All the best practices in "OAuth 2.0 for Browser-Based Applications" would apply.

  • ⚡ Token exchange by itself doesn't provide a way for the AS to tell the client what extra evidence is required. This approach could be used for any OAuth grant type. Which is why this can't be done on a distinct incremental endpoint.

  • ⚡ Making the OAuth token endpoint stateful probably violates one of the original design objectives. This would make an already complex endpoint even more complex. It's such a big change that it's hard to see large SaaS IDPs supporting it any time soon.

Livestream Audio Archive