OIDC et OAuth

Points de terminaison de découverte, d'autorisation, de jeton, de 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 d’actualisation, PAR, preuve DPoP et liaison `dpop_jkt`, enregistrement client dynamique, jetons d’identification, informations utilisateur, types de réponse hybrides, objets de requête JAR signés, réponses JARM signées, détails d’autorisation RAR `resource_access`, échange de jetons, authentification client mTLS, déconnexion des canaux avant et arrière, flux de périphériques, gestion de session, CIBA, portes de profil d’applications basées sur le navigateur et Portails profilés FAPI 2.0.
Mise en œuvre minimale	OpenID Federation expose uniquement les métadonnées d’entité et une limite d’enregistrement. La résolution de la chaîne de confiance, les ancres de confiance, le traitement des politiques et l’interopérabilité de la production ne sont pas mis en œuvre.
Planifié	Shared Signals, CAEP, RISC, GNAP, UMA, HEART, OpenID4VP et OpenID4VCI exposent des routes réservées qui renvoient des erreurs 501 explicites. Ce ne sont pas des implémentations de protocole.
Preuve de production	La mise en œuvre locale et les contrôles de conformité ne constituent pas une certification de production. L’OIDC SaaS en aval utilise la référence générique OIDC, mais chaque intégration SaaS nécessite toujours de véritables preuves externes 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	Seuls les talons de route et de métadonnées négatifs sont exposés. Les opérations non prises en charge renvoient explicitement `501 unsupported_feature` ; aucune prise en charge de protocole fonctionnel n’est revendiquée.