OIDC e OAuth

Endpoints de discovery, autorização, token, logout e extensões OAuth.

Ver como Markdown

Endpoints principais

Endpoint	Descrição
`/.well-known/openid-configuration`	Descoberta OIDC para o emissor atual.
`/.well-known/oauth-protected-resource`	Metadados de recurso protegido OAuth para endpoints de recursos hospedados no XID.
`/jwks`	Chaves públicas de assinatura da instância com identificadores kid ativos e em rotação.
`/authorize`	Endpoint de autorização com PKCE, state, nonce, PAR e transferência para Hosted Auth.
`/par`	Pushed Authorization Requests com valores request_uri de uso único.
`/token`	Código de autorização, token de atualização, credenciais de cliente, código de dispositivo e troca de token.
`/userinfo`	Declarações de usuário de token de acesso Bearer ou DPoP.
`/end_session`	Logout iniciado pelo RP com redirecionamentos pós-logout registrados.

Requisitos de protocolo

PKCE usa S256. PKCE plain é rejeitado.
A correspondência de URI de redirecionamento é exata. Curingas não são aceitos.
Códigos de autorização são de uso único.
Tokens de atualização rotacionam a cada uso, e repetição revoga a família de tokens.
Clientes vinculados a DPoP devem apresentar uma prova DPoP valida para chamadas de token e recursos. O dpop_jkt da solicitacao de autorizacao fica vinculado ao authorization code exchange.

Níveis de suporte

Nível	Recursos OAuth e OIDC
Implementado	Código de autorização, PKCE S256, rotação de refresh, PAR, prova DPoP e vínculo `dpop_jkt`, registro dinâmico de clientes, ID tokens, userinfo, tipos de resposta híbridos, objetos de requisição JAR assinados, respostas JARM assinadas, detalhes de autorização RAR`resource_access`, refresh de token exchange e emissão de ID token, autenticação de cliente mTLS e logout front-channel.
Provider-ready	Polling de autorização de dispositivo, check_session do Session Management, aprovação CIBA backchannel, gates de perfil FAPI 2.0 / Browser-Based Apps, OpenID Federation e Shared Signals expõem subconjuntos limitados ou provider-ready. GNAP, UMA, HEART, OpenID4VP e OpenID4VCI retornam stubs negativos ou 501 até os perfis completos estarem disponíveis.
Planejado	OIDC SaaS downstream usa localmente a baseline OIDC genérica atual, mas suporte de produção específico de SaaS ainda exige SaaS L4 real.
Obsoleto ou sem suporte	Fluxo implícito, password grant, PKCE plain e redirects curinga.

Limites do papel

Papel do XID	Status público atual
Provedor de identidade OIDC / OAuth para aplicativos de clientes	Implementado em rotas locais e do Worker com cobertura de código de autorização, PKCE S256, PAR, DPoP, JAR, JARM, RAR, discovery, JWKS, token, userinfo, introspecção e revogação.
Relying party OIDC corporativa upstream	Status provider-ready para conexões corporativas. O suporte em produção requer uma configuração de IdP real e uma L4 de callback.
Relying party de OAuth social	Status provider-ready para GitHub, Google, contas da Microsoft e Apple. Consulte Login social para conhecer os limites específicos de cada provedor.
Provedor de identidade OIDC para SaaS downstream	A base genérica de OIDC está disponível localmente. Modelos de aplicativos específicos de SaaS e uma L4 real de SaaS ainda são necessários antes de declarar suporte em produção.

Tipos de cliente

Cliente	Fluxo recomendado
Aplicativo web	Código de autorização com troca de token no servidor.
SPA	Código de autorização com PKCE S256.
Aplicativo nativo	Código de autorização com PKCE S256 e redirecionamentos declarados.
Máquina para máquina	Credenciais de cliente com acesso escopado.

Extensões OAuth e OIDC limitadas ou mínimas

Nível	Estado
Grants de assercao	Assertion grants JWT bearer e SAML bearer nao estao habilitados. O registro rejeita metadados de assertion grant ate existir uma raiz de confianca.
GNAP, UMA, HEART, OpenID4VP, OpenID4VCI	Subconjuntos mínimos de rotas e metadados amigáveis a discovery são expostos. Operações não suportadas retornam erros explícitos até os handlers de perfil completos estarem disponíveis.