Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Replace experimental jwt-bearer client flag with a grant-types-enabled config

Aperta
#4,231 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
52/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
go

Direzione di ricerca

Inizia in auth/cmd e auth/config.go per tracciare la registrazione e il caricamento della nuova impostazione grant-types-enabled, quindi segui la costruzione di OpenID4VPClient e AuthorizationServerMetadata. Aggiorna i test interessati, server_options.rst e le note di rilascio; il lavoro è completato quando l’insieme abilitato controlla sia il comportamento del client sia i grant_types_supported pubblicizzati, e il vecchio flag è stato rimosso.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

auth

Background

PR #4227 added auth.experimental.jwt_bearer_client (bool, default false) to gate the new RFC 7523 jwt-bearer two-VP client flow. During review @reinkrul suggested replacing it with a list-style config so the same mechanism can later enable/disable other grant types (authorization_code, vp_token-bearer, openid4vp, etc.).

We agreed to defer the refactor (rather than do it inside #4227) because doing it properly means touching every grant type that we currently support unconditionally, not just the new one.

Proposed change

Introduce a list-style config:

auth.granttypesenabled: [authorization_code, urn:ietf:params:oauth:grant-type:vp_token-bearer]
  • Default: the grant types we currently support without a flag (authorization_code, vp_token-bearer).
  • Operators opt into the experimental two-VP flow by appending urn:ietf:params:oauth:grant-type:jwt-bearer.
  • Drop auth.Config.Experimental.JwtBearerClient once the new config is in place.

Knock-on: AS metadata advertisement

The same config should drive what the local Authorization Server advertises in its metadata under grant_types_supported. Today the metadata is built from a fixed list; once the config exists, the metadata builder must read from it so AS clients can negotiate correctly.

This is the main reason we deferred the refactor out of #4227: the metadata thread reaches further than the client-side gate, and doing it half-way would hide the change from any peer node fetching our AS metadata.

Scope

  • New config field + flag registration in `auth/cmd` and `auth/config.go`.
  • Replace the `OpenID4VPClient.experimentalJwtBearerClient bool` with a membership check against the enabled set.
  • Wire the same set into `AuthorizationServerMetadata.GrantTypesSupported` construction.
  • Migrate / remove `auth.experimental.jwt_bearer_client`.
  • Update tests, docs (`server_options.rst`), and the release notes.

Related

  • PR #4227 — introduced the boolean flag this issue replaces.
  • PRD #4078 — overall RFC 7523 jwt-bearer client work.
Lingua principale
Go
Stelle
29
Fork
24
Merge medio
2g 18h
PR unite (30g)
45

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di nuts-foundation/nuts-node

Tutte le issue di nuts-foundation/nuts-node

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.