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

Ouverte
#512 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
25/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
typescript

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
TypeScript
Étoiles
2
Forks
2
Merge moyen
11 h 40 min
PR mergées (30 j)
104

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de fells-code/seamless-auth-api

Toutes les issues de fells-code/seamless-auth-api

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.