OIDC et OAuth

Points de terminaison de découverte, autorisation, jeton, déconnexion et extensions OAuth.déconnexion et d'extensions OAuth.

Points de terminaison principaux

Point de terminaison	Description
`/.well-known/openid-configuration`	Découverte OIDC pour l’émetteur actuel.
`/.well-known/oauth-protected-resource`	Metadonnees de ressource protegee OAuth pour les endpoints de ressources heberges par XID.
`/jwks`	Clés publiques de signature de l’instance avec des kid actifs et en rotation.
`/authorize`	Point de terminaison d’autorisation avec PKCE, state, nonce, PAR et transfert vers l’authentification hébergée.
`/par`	Requêtes d’autorisation poussées avec des valeurs request_uri à usage unique.
`/token`	Code d’autorisation, jeton d’actualisation, identifiants client, code appareil et échange de jeton.
`/userinfo`	Revendications utilisateur du jeton d’accès Bearer ou DPoP.
`/end_session`	Déconnexion initiée par le RP avec redirections post-déconnexion enregistrées.

PKCE utilise S256. PKCE sans transformation est rejeté.
La correspondance des URI de redirection est exacte. Les caractères génériques ne sont pas acceptés.
Les codes d’autorisation sont à usage unique.
Les jetons d’actualisation tournent à chaque utilisation et un rejeu révoque la famille de jetons.
Les clients lies a DPoP doivent presenter une preuve DPoP valide pour les appels token et resource. Le dpop_jkt de la requete d autorisation est lie a l echange du authorization code.

Niveau	Fonctionnalités OAuth et OIDC
Implémenté	Code d’autorisation, PKCE S256, rotation des refresh tokens, PAR, preuve DPoP et liaison `dpop_jkt`, enregistrement dynamique des clients, ID tokens, userinfo, types de réponse hybrides, objets de requête JAR signés, réponses JARM signées, détails d’autorisation RAR`resource_access`, refresh token-exchange et émission d’ID token, authentification client mTLS et déconnexion front-channel.
Provider-ready	Le polling d’autorisation d’appareil, check_session Session Management, l’approbation CIBA backchannel, les portes de profil FAPI 2.0 / Browser-Based Apps, OpenID Federation et Shared Signals exposent des sous-ensembles limités ou provider-ready. GNAP, UMA, HEART, OpenID4VP et OpenID4VCI renvoient des stubs négatifs ou 501 jusqu’à l’arrivée des profils complets.
Planifié	OIDC SaaS en aval utilise localement la base OIDC générique actuelle, mais le support de production spécifique SaaS exige encore un vrai SaaS L4.
Déprécié ou non pris en charge	Flux implicite, password grant, PKCE plain et redirections avec joker.

Rôle de XID	Statut public actuel
Fournisseur d’identité OIDC / OAuth pour les applications clientes	Implémenté dans les routes locales et Worker avec une couverture du code d’autorisation, de PKCE S256, PAR, DPoP, JAR, JARM, RAR, de discovery, JWKS, token, userinfo, introspection et revocation.
Partie de confiance OIDC d’entreprise en amont	Provider-ready pour les connexions d’entreprise. La prise en charge en production requiert une configuration d’IdP réelle et un callback L4.
Partie de confiance OAuth sociale	Provider-ready pour GitHub, Google, les comptes Microsoft et Apple. Consultez Connexion sociale pour connaître les limites propres à chaque fournisseur.
Fournisseur d’identité OIDC pour SaaS en aval	Une base OIDC générique est disponible localement. Des modèles d’application propres à chaque SaaS et un L4 SaaS réel sont encore requis avant toute déclaration de prise en charge en production.

Client	Flux recommandé
Application web	Code d’autorisation avec échange de jeton côté serveur.
SPA	Code d’autorisation avec PKCE S256.
Application native	Code d’autorisation avec PKCE S256 et redirections déclarées.
Machine à machine	Identifiants client avec accès limité.

Niveau	Statut
Grants d’assertion	Les assertion grants JWT bearer et SAML bearer ne sont pas actives. L’enregistrement rejette les metadonnees d’assertion grant jusqu’a l’existence d’une racine de confiance.
GNAP, UMA, HEART, OpenID4VP, OpenID4VCI	Des sous-ensembles de routes minimales et des métadonnées adaptées à la découverte sont exposés. Les opérations non prises en charge renvoient des erreurs explicites jusqu’à l’arrivée des gestionnaires de profil complets.