---
title: "OIDC et OAuth"
description: "Points de terminaison de découverte, autorisation, jeton, déconnexion et extensions OAuth.déconnexion et d'extensions OAuth."
locale: "fr"
---

> Documentation Index
> Fetch the locale documentation index at: https://xid.dev/fr/llms.txt
> Use this file to discover all available pages before exploring further.

# OIDC et 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. |

## Exigences de protocole

- 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.

## Niveaux de prise en charge

| 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. |

## Limites des rôles

| 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. |

## Types de clients

| 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é. |

## Extensions OAuth et OIDC limitées ou minimales

| 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. |

Source: https://xid.dev/fr/oidc-oauth/index.mdx