feat: sender-constrained tokens with DPoP (RFC 9449)

Offen
#512 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
25/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
typescript

Rechercherichtung

Start by reading RFC 9449 and the project plan in #392 to understand the intended DPoP support. Then locate the token endpoint and its client policy and token issuance paths; the issue names no files or tests. Done means refresh tokens are bound to the presenting key, required clients are refused without a proof, and server nonces limit proof replay.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

P2 secure v2.1

Why

A refresh token held by a desktop, mobile or single-page app is a bearer credential: anyone who copies it can use it. Rotation with reuse detection limits the damage after the fact. Sender-constrained tokens prevent it, because a token is only usable with a private key the client holds, ideally one that cannot leave the device (a TPM, Secure Enclave or platform keystore). RFC 9700 recommends sender constraint for public clients' refresh tokens, and #392 lists DPoP for v2.1 without a ticket yet.

What

  • DPoP (RFC 9449) at the token endpoint: a client presents a DPoP proof, and the access and refresh tokens are bound to its key (cnf.jkt).
  • Per-client policy: DPoP optional, or required (for example, required for every public client).
  • Server nonces (DPoP-Nonce) to limit proof replay.
  • Resource servers and adapters verify the proof and the binding (tracked in the adapter repos).
  • Notes for clients on holding the key in hardware where the platform allows it: a TPM on Windows and Linux, the Secure Enclave on macOS and iOS, StrongBox on Android.

Done when

A refresh token issued to a DPoP client cannot be used without a proof from the same key, and a client with DPoP required is refused without one.

Vorherrschende Sprache
TypeScript
Sterne
2
Forks
2
Ø Merge
11 Std. 40 Min.
Gemergte PRs (30 T.)
104

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus fells-code/seamless-auth-api

Alle Issues in fells-code/seamless-auth-api

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.