Minutes interim-2025-oauth-03: Mon 17:00
minutes-interim-2025-oauth-03-202501201700-00
| Meeting Minutes | Web Authorization Protocol (oauth) WG | |
|---|---|---|
| Date and time | 2025-01-20 17:00 | |
| Title | Minutes interim-2025-oauth-03: Mon 17:00 | |
| State | Active | |
| Other versions | markdown | |
| Last updated | 2025-02-06 |
OAuth Working Group Interim Meeting
-
Date: 20.Jan.2025
-
Minute Taker: Hannes Tschofenig
Single-Use Tokens (Dmitry)
There are one-time use tokens available in OAuth, such as authorization
codes and DPoP proofs.
Use cases from the financial sector
The difference between regular access tokens on single-use tokens. There
is, for example, no refresh token.
Single use token is different from step-up authentication. The ACR claim
is updated with th step-up authentication.
In KeyCloak, single-use tokens are configured via a different client.
Solution: Client does not replace the current access token. New "use"
claim to indicate single use.
Hannes asked for a clarification regarding the use cases. The payment
use cases are
Pieter: Single-Use is tricky at scale. You send a token and the
recipient did not receive it. You also have to monitor the one-time use.
Dmitry: We need to solve the issue of a clustered RS. I do not know how
you solve this problem with DPoP.
Pieter: One of the ways to solve this problem is to ignore the
requirement. The security properties you associate with one-time use are
solved in a soft way. You attribute too much on the one-time-ness. It
might not be practical. Synchronization in the background can go wrong.
It is innocent to have this one-time token idea but then in practice it
gets complex.
There is a best effort.
Dmitry: The problems should be equal to DPoP proofs.
Filip: Agree with Pieter. When it comes to practical deployment we try
to be consistent - eventually. It is best effort at this scale. The DPoP
does not say it is one-time use. I do not think many people check.
Hannes describes the case of DPoP.
Filip: Even in the authorization code example the treatment is
different. It is eventually consistent.
Dmitry: How common is it for a client to hold an access token in a
single variable?
Filip: Not common.
Hannes clarified the use of Javascript (server-side vs. browser-based)
and pointed to the SPA document from the IETF OAuth WG, which has just
been sent to the IESG.
Closed the call early.