OpenID Connect (OIDC): ID Tokens, Sessões e Federação de Identidade
Da autenticação do usuário à validação de ID Tokens, UserInfo, níveis de assurance, SSO e logout federado
Edição aprofundada - material de estudo e consulta profissional
Por João Ricardo Dutra••Material integral
Apresentação do capítulo
O capítulo anterior aprofundou como estrutura de autorização delegada. permite que um cliente obtenha autoridade limitada para acessar um resource server, mas não define, sozinho, uma forma padronizada de comunicar ao cliente que um usuário foi autenticado. acrescenta essa camada de identidade ao utilizar os e mecanismos do , introduzindo o escopo openid, o , padronizadas, , e regras específicas de validação.
Essa distinção é decisiva em arquiteturas corporativas. O é destinado à ; o é destinado ao cliente que iniciou a autenticação. Uma aplicação web pode validar o e criar sua própria sessão, enquanto apresenta separados ao . Encaminhar o ao como se fosse credencial de mistura destinatários, amplia exposição de dados pessoais e cria validações incorretas.
também organiza problemas que vão além do primeiro login: níveis de autenticação, , step-up, identidade federada, consentimento de , identificadores de sujeito, descoberta de , rotação de chaves, sessões distribuídas e logout. Em ambientes com múltiplos tenants e provedores, a segurança depende de associar cada ao issuer correto e de evitar que ou chaves de um domínio sejam aplicados a outro.
Este capítulo detalha o Flow com sob a perspectiva , a anatomia e validação do ,, state, ,, auth_time, , subject identifiers, sessões e mecanismos de logout. Também relaciona os conceitos a aplicações web, SPAs, BFFs, aplicativos nativos, Axway , e .
Como estudar este capítulo
Em cada fluxo, marque quatro destinatários: navegador, cliente , e . Depois, associe cada artefato ao destinatário correto: ,,,, de sessão e logout .
Objetivos de aprendizagem
Explicar por que é uma camada de identidade construída sobre .
Diferenciar ,,, Authorization Server e Resource Server.
Descrever o Flow com openid, state, e .
Interpretar e validar , incluindo ,, aud, , exp, iat, , auth_time, e .
Distinguir ,,, e resposta .
Compreender de identidade e solicitadas, essenciais e voluntárias.
Projetar identificadores public e pairwise sem usar e-mail como chave imutável.
Relacionar ,, max_age e a , step-up e políticas de risco.
Distinguir sessão no , sessão no cliente e autorização perante .
Comparar RP-Initiated, Front-Channel e .
Usar e com validação de issuer, algoritmos e rotação de chaves.
Diagnosticar falhas em aplicações, e ambientes federados.
Estrutura do capítulo
17.1 como camada de identidade sobre
17.2 Papéis, e artefatos
17.3 A solicitação de autenticação e o openid
17.4 Flow com
17.5 : finalidade, formato e
17.6 Validação segura do
17.7 state, ,, c_hash e at_hash
17.8 e de identidade
17.9
17.10 Subject identifiers: public e pairwise
17.11 ,, auth_time, max_age e
17.12 , step-up e contexto de autenticação
17.13 Sessões no OP, no RP e perante
17.14 Logout iniciado pelo RP
17.15 Front-Channel e
17.16 , e
17.17 Registro de clientes e redirect
17.18 Federação de identidade e cadeia de confiança
17.19 Multi-tenant, múltiplos issuers e account linking
17.20 Aplicações web, , e aplicativos nativos
17.21 em , Axway e
17.22 Ameaças e hardening
17.23
17.24 Estudos de caso e laboratórios
Resumo, checklist, exercícios, glossário e referências
17.1 como camada de identidade sobre
define uma camada de identidade que permite ao cliente verificar a identidade do usuário com base em uma autenticação realizada por um Authorization Server que também atua como . O protocolo reutiliza o authorization , o e os grants do , mas adiciona semântica de autenticação e um conjunto de mensagens e validações próprias.
A ativação de ocorre quando a solicitação contém o openid. Sem esse valor, a transação permanece e o cliente não deve assumir que receberá um . Outros , como profile, email, address e phone, solicitam conjuntos padronizados de , mas não substituem o openid.
O principal resultado de autenticação é o , uma asserção de segurança sobre o evento de autenticação e sobre o identificador do usuário no contexto daquele issuer. O cliente valida essa asserção e decide criar ou atualizar uma sessão local. O não é uma consulta em tempo real ao diretório e não garante que todos os atributos permaneçam atuais durante toda a sessão.
Distinção essencial
responde “qual autoridade este cliente recebeu para acessar um recurso?”. responde “qual usuário foi autenticado para este cliente, por qual emissor e sob quais condições?”. Um sistema pode usar ambos na mesma transação sem confundir seus .
17.2 Papéis, e artefatos
O é a pessoa autenticada. O , ou RP, é o cliente que solicita e consome a autenticação. O , ou OP, autentica o usuário e emite . Em muitas plataformas, o mesmo produto exerce os papéis de OP e Authorization Server, mas a análise conceitual continua separando autenticação para o cliente e autorização para .
O authorization interage com o navegador para login, consentimento e retorno ao redirect . O recebe o por back-channel e devolve . O é um recurso protegido acessado com . O de publica , e o jwks_uri referencia as chaves públicas usadas na verificação de assinaturas.
Os artefatos possuem ciclos de vida diferentes. O é curto e de uso único. O descreve a autenticação para o RP. O representa autoridade perante um resource server. O permite obter novos conforme política. mantêm sessões no OP ou no RP e não devem ser tratados como equivalentes aos .
Tabela 1 - Cada artefato possui destinatário e finalidade próprios.
Elemento
Destinatário principal
Finalidade
Representar temporariamente a autorização e vincular front-channel ao back-channel.
Comunicar identidade e contexto da autenticação ao cliente.
Resource Server /
Autorizar operações protegidas.
Authorization Server
Obter novos sem repetir toda a interação.
Entregar autorizadas sobre o usuário.
do OP
Manter a sessão de autenticação federada.
do RP
Aplicação cliente
Manter a sessão local da aplicação.
Figura 1 - O code trafega pelo navegador, mas os são obtidos no por canal direto.
17.3 Solicitação de autenticação e openid
A solicitação é uma authorization acrescida de requisitos de identidade. Os parâmetros usuais incluem client_id, response_type, redirect_uri, , state, , code_challenge e code_challenge_method. Outros parâmetros, como , max_age, login_hint, ui_locales e acr_values, orientam a experiência ou o nível de autenticação desejado, desde que suportados pelo OP.
O redirect_uri precisa corresponder a um valor previamente registrado. Comparações flexíveis, curingas amplos e redirecionamentos derivados de externos aumentam o risco de desvio do code e de . O cliente deve gerar state, e code_verifier com entropia suficiente para cada tentativa e associá-los à transação local antes de redirecionar o navegador.
O parâmetro deve conter openid. adicionais indicam grupos de que o cliente solicita, mas o OP ainda aplica política, consentimento e minimização. Solicitar profile não garante que todas as do conjunto serão retornadas no ; algumas podem aparecer em ou ser omitidas.
No fluxo recomendado, o navegador é redirecionado ao authorization , o OP autentica o usuário e retorna um ao redirect do cliente. O cliente valida state e envia o code ao junto ao code_verifier. Um cliente confidencial também se autentica no por mecanismo compatível, preferencialmente credencial assimétrica ou método adequado ao ambiente.
O vincula o code à instância que iniciou a transação. O code_challenge foi enviado na solicitação inicial e o code_verifier é revelado apenas na troca. Mesmo que um atacante intercepte o code, não consegue trocá-lo sem o verifier. não substitui state nem : cada valor protege uma relação diferente.
A resposta do pode conter ,, token_type, expires_in e, conforme política, . O cliente não deve criar uma sessão somente porque recebeu 200. Primeiro valida a resposta, o , o issuer, a audience, a assinatura, a janela temporal, e demais requisitos do fluxo.
Figura 2 - O é uma asserção destinada ao cliente , não uma credencial universal.
17.5 : finalidade, formato e
O é um que contém sobre a autenticação do usuário. Ele é assinado pelo OP e pode, em cenários específicos, também ser criptografado para o cliente. A assinatura oferece integridade e autenticação da origem; não oferece confidencialidade. Qualquer sensível incluída em um apenas assinado pode ser lida por quem obtiver o valor.
As fundamentais incluem , que identifica o emissor; , que identifica o usuário de forma local ao issuer; aud, que identifica o cliente destinatário; exp e iat, que delimitam validade e emissão. Dependendo do fluxo e da solicitação, aparecem , auth_time, ,,, at_hash e c_hash.
O cliente deve usar a combinação e como chave externa estável. E-mail, telefone e nome são atributos mutáveis e podem ser reciclados. Em arquiteturas multi-tenant, o tenant ou o issuer completo também participa da identidade; usar apenas sem contexto pode produzir colisões entre emissores.
Mesmo quando ambos são e compartilham algumas , seus destinatários e semânticas são diferentes. A deve validar o emitido para sua audiência; o cliente valida o emitido para seu client_id.
Figura 3 - A verificação criptográfica é apenas uma etapa da validação contextual.
17.6 Validação segura do
O cliente deve comparar com o issuer esperado de forma exata. Em seguida, seleciona uma chave confiável para verificar a assinatura e restringe algoritmos aos explicitamente aceitos. O valor alg do próprio não pode decidir sozinho a política. O kid auxilia a seleção de chave, mas não substitui a confiança no jwks_uri associado ao issuer.
A aud precisa conter o client_id do RP. Quando há múltiplas audiences, identifica a parte autorizada e deve ser avaliada conforme as regras do protocolo. exp deve estar no futuro dentro da tolerância de relógio; iat não pode ser absurdamente distante; auth_time é validado quando a solicitação exige idade máxima da autenticação.
Se foi enviado, o deve conter o mesmo valor associado à tentativa local. de segurança como e somente devem ser usadas quando sua semântica é documentada e confiável naquele issuer. A presença de uma string parecida com “” não cria, por si só, garantia interoperável de nível de assurance.
Bibliotecas maduras realizam grande parte das verificações, mas ainda exigem configuração correta de issuer, client_id, algoritmos, redirect e armazenamento de estado. Decodificar o manualmente e observar não equivale a validá-lo.
Tabela 2 - A aceitação do depende de validações criptográficas e semânticas.
Verificação
Falha evitada
Evidência
exato
Aceitar de emissor não autorizado
Issuer obtido de configuração confiável.
Assinatura e alg
adulterado ou algoritmo indevido
correspondente e allowlist de algoritmos.
aud /
emitido para outro cliente
client_id presente e parte autorizada coerente.
exp / iat /
fora da janela ou sessão antiga
Relógio sincronizado e tolerância limitada.
Reuso ou substituição de resposta de autenticação
Valor por transação armazenado no cliente.
/
Aceitar autenticação abaixo do requisito
Semântica definida pelo issuer e política local.
17.7 state, ,, c_hash e at_hash
state vincula a resposta de autorização à transação iniciada pelo cliente e auxilia a proteção contra e injeção de respostas. vincula o à solicitação de autenticação e reduz de . vincula a troca do à instância que produziu o code_challenge. Os três valores podem coexistir e não devem ser reutilizados entre tentativas.
Em types que retornam artefatos pelo authorization , c_hash e at_hash podem vincular, respectivamente, o e o ao . A validação usa parte do calculado com algoritmo relacionado à assinatura. Em um fluxo code puro, a biblioteca pode não exigir ambos, mas o implementador precisa seguir as regras do type realmente utilizado.
Armazenar esses valores apenas em variáveis globais ou em localStorage sem vínculo a uma tentativa permite colisões e ataques por abas concorrentes. O cliente deve manter um registro de transação com issuer, client_id, redirect_uri, state, , code_verifier, horário e parâmetros esperados, removendo-o após sucesso ou expiração.
Valor O que vincula Onde é validado
Tabela 3 - Valores de correlação protegem relações distintas do fluxo.
Valor
O que vincula
Onde é validado
state
Solicitação e resposta de autorização
No , antes de processar code ou erro.
Solicitação e
Dentro do após validação de assinatura.
code_verifier
Authorization e
No pelo OP.
e
No cliente quando exigido pelo type.
at
e
No cliente quando exigido pelo type.
17.8 e de identidade
define padronizadas para perfil, e-mail, endereço e telefone. como profile e email são atalhos para solicitar conjuntos de . A resposta efetiva depende do OP, do consentimento, da política e do local de entrega. Uma pode aparecer no , na resposta ou em ambos.
O parâmetro permite solicitar individualmente e indicar se são essenciais. “Essential” expressa requisito do cliente, mas não obriga um OP incapaz a fabricar o dado; a transação pode falhar ou prosseguir conforme suporte e política. Valores esperados também podem ser informados para algumas , exigindo cuidado com interoperabilidade.
Minimização é uma propriedade de segurança e privacidade. O cliente deve solicitar apenas os atributos necessários e evitar persistir cópias indefinidas. de grupos e roles podem crescer, variar entre diretórios ou representar estado administrativo; não devem ser tratadas como substitutas universais de autorização de objeto e de regras do domínio.
O é um recurso protegido que retorna sobre o usuário associado ao . O cliente chama esse com ou mecanismo sender-constrained, conforme o perfil adotado. A resposta normalmente é assinado ou não, dependendo da configuração e dos do OP.
O cliente precisa validar que a de é idêntica ao do . Essa comparação impede que de outro usuário sejam associadas à sessão atual. O fato de a conexão usar não elimina essa validação semântica.
é útil quando o cliente precisa de que não deveriam aumentar o ou quando o OP aplica entrega seletiva. Entretanto, cada chamada adiciona dependência de rede e tratamento de indisponibilidade. O desenho deve decidir quais dados são necessários no login, quais podem ser carregados sob demanda e por quanto tempo podem ser armazenados.
Cuidado com dados pessoais
e podem conter dados pessoais. Não registre respostas completas em , ou ferramentas de erro. Prefira identificadores mínimos, mascaramento e controles de retenção alinhados à finalidade.
17.10 Subject identifiers: public e pairwise
A fornece um identificador localmente único e nunca reatribuído dentro do issuer. No modo public, o mesmo usuário tende a receber o mesmo para diferentes clientes. No modo pairwise, o OP calcula um identificador diferente por setor de clientes, reduzindo a possibilidade de correlacionar o usuário entre aplicações independentes.
identifiers são relevantes para privacidade, mas exigem planejamento de account linking, suporte e migração. Dois clientes do mesmo setor podem compartilhar o mesmo conforme a política do OP; clientes de setores diferentes recebem valores distintos mesmo para a mesma pessoa.
O banco da aplicação deve persistir issuer e como chave federada, mantendo atributos como e-mail em campos atualizáveis. Quando há migração de issuer, fusão de tenants ou troca de estratégia de subject, a associação precisa de procedimento explícito e prova adicional; não deve ser inferida apenas por coincidência de e-mail.
Tabela 4 - O identificador de sujeito deve equilibrar estabilidade e privacidade.
Estratégia
Vantagem
Atenção operacional
Facilita correlação entre clientes do mesmo issuer.
Aumenta possibilidade de rastreamento entre aplicações.
Reduz correlação entre setores de clientes.
Exige sector identifier e planejamento de linking.
E-mail como chave
Parece simples para o negócio.
É mutável, pode ser reciclado e não é identificador seguro.
+
Identidade federada estável no domínio do emissor.
Precisa ser preservada em migrações e multi-tenant.
17.11 ,, auth_time, max_age e
representa uma classe ou contexto de autenticação alcançado, conforme vocabulário do issuer ou de um perfil. lista métodos utilizados, como senha, OTP, biometria ou hardware, mas os valores e combinações precisam ser interpretados conforme documentação do OP. auth_time registra quando a autenticação ativa ocorreu.
O cliente pode usar max_age para exigir que a autenticação não seja mais antiga que determinado limite. Quando max_age é solicitado, auth_time torna-se essencial para a verificação. controla a interação: none tenta autenticação silenciosa; login força nova autenticação; consent força nova decisão de consentimento; select_account solicita escolha de conta, conforme suporte.
acr_values expressa preferência por contextos de autenticação. Em operações de alto risco, o cliente pode iniciar um novo fluxo com requisito mais forte. A política não deve confiar apenas em parâmetros enviados pelo front-end; o OP e o cliente precisam validar que o contexto retornado satisfaz a regra da operação.
Tabela 5 - e parâmetros descrevem recência e contexto de autenticação.
/ parâmetro
Significado
Uso típico
Classe de contexto de autenticação alcançada
Comparar com nível exigido pela operação.
Métodos utilizados na autenticação
Auditoria e políticas específicas do issuer.
Instante da autenticação ativa
Validar e recência.
Idade máxima aceitável da autenticação
Forçar reautenticação para operação sensível.
Comportamento de interação solicitado
none, login, consent ou select account.
17.12 , step-up e contexto de autenticação
significa utilizar fatores independentes, não apenas duas etapas do mesmo fator. O RP normalmente não implementa os autenticadores; ele solicita ou verifica um contexto emitido pelo OP. Para uma operação de alto risco, o cliente pode iniciar step-up e exigir nova autenticação com ou política equivalente.
A decisão deve considerar a autenticação já realizada, o risco atual, o dispositivo, o recurso e o tempo desde a última prova. Um usuário pode ter sessão válida no OP, mas ainda precisar de uma autenticação adicional para autorizar pagamento, alterar credenciais ou acessar dados sensíveis.
O resultado de step-up precisa ser vinculado à operação ou à sessão apropriada. Aceitar um antigo que continha , sem avaliar auth_time e o contexto da transação, permite reutilização indevida. Em sistemas críticos, a confirmação de negócio pode exigir controles além de , como assinatura transacional ou aprovação independente.
Princípio de assurance
Não trate e como strings universais. Defina quais valores cada issuer pode emitir, o que significam, como são auditados e quais operações aceitam cada nível. Em federações, esse mapeamento precisa fazer parte do acordo de confiança.
Figura 4 - , sessão local e autorização de são estados relacionados, mas independentes.
17.13 Sessões no OP, no RP e perante
A sessão no OP permite Single Sign-On entre clientes que confiam no mesmo provedor. Ela costuma ser representada por sob o domínio do OP. Quando outro RP envia uma authorization , o OP pode reutilizar a autenticação existente, desde que política, e max_age permitam.
A sessão no RP é criada pela aplicação após validar o . Em uma aplicação web tradicional ou , um HttpOnly, Secure e com SameSite adequado referencia estado no servidor. Em pura, bibliotecas podem manter no navegador, o que aumenta a importância de proteção contra e reduz as garantias de confidencialidade de segredos.
A normalmente valida a cada chamada e não conhece o do OP nem o do RP. Expirar a sessão local impede novas ações pelo navegador, mas não necessariamente revoga já emitidos. Da mesma forma, revogar um não limpa automaticamente todos os de sessão.
O desenho de sessão precisa definir tempos absolutos e de inatividade, renovação, rotação, revogação, reautenticação e comportamento em múltiplos dispositivos. A experiência “sair de todos os lugares” exige inventário e coordenação entre sessões e .
17.14 Logout iniciado pelo
No , o cliente redireciona o navegador ao de logout do OP. Parâmetros comuns incluem id_token_hint, post_logout_redirect_uri, client_id e state, conforme suporte e regras do provedor. O post_logout_redirect_uri deve estar previamente registrado para evitar redirecionamento aberto.
id_token_hint auxilia o OP a identificar a sessão e o cliente, mas não deve ser tratado como de acesso. state pode correlacionar o retorno pós-logout e proteger a navegação. O RP deve limpar sua sessão local independentemente de o redirecionamento final ocorrer, evitando que uma falha de rede mantenha o usuário aparentemente autenticado na aplicação.
Logout iniciado pelo RP não garante, sozinho, que todas as outras aplicações conectadas ao OP sejam encerradas. O OP pode oferecer propagação por front-channel ou back-channel. A política de produto precisa deixar claro se “sair” significa encerrar apenas a aplicação atual, a sessão do provedor ou todas as sessões conhecidas.
Exemplo conceitual -
GET /logout?
id_token_hint=eyJ...
&post_logout_redirect_uri=https%3A%2F%2Fportal.example%2Fsigned-out
&state=bG9nb3V0LXRyYW5zYWN0aW9u HTTP/1.1
Host: id.example
Figura 5 - Os mecanismos de logout diferem pelo canal usado e pela dependência do navegador.
17.15 Front-Channel e
utiliza o user agent para carregar de logout dos RPs. O mecanismo é simples e compatível com aplicações web, mas depende do navegador, de e da conclusão das navegações. Restrições a de terceiros e iframes podem reduzir a confiabilidade em alguns ambientes.
envia uma requisição direta do OP ao registrado pelo RP. O corpo contém um logout assinado, com eventos específicos e identificadores como ou . O RP valida issuer, audience, assinatura, tempo, jti e evento antes de invalidar a sessão correspondente. O deve ser idempotente, resiliente e não depender de do navegador.
Management e de estado também podem detectar mudanças, mas o desenho deve preferir mecanismos finais e suportados pelo ecossistema. Nenhum logout substitui expiração curta de , revogação quando aplicável e autorização contínua para operações de alto risco.
Tabela 6 - Logout precisa ser projetado como propagação de estado, não como um único redirect.
Mecanismo
Canal
Pontos fortes
Limitações
RP-Initiated
Navegador do RP ao OP
Experiência explícita de saída.
Não propaga sozinho a todos os RPs.
Front-Channel
Navegador do OP aos RPs
Implementação web direta.
Depende do user agent, e rede.
Back-Channel
OP chama do RP
Não depende do navegador; mais determinístico.
Exige , validação e tratamento resiliente.
Expiração local
Controle do próprio RP
Sempre disponível e simples.
Não encerra sessão do OP ou de outros RPs.
17.16 , e
publica um documento de configuração em um endereço well-known derivado do issuer. O documento informa authorization_endpoint, token_endpoint, userinfo_endpoint, jwks_uri, end_session_endpoint quando disponível, types, ,, métodos de autenticação de cliente e algoritmos suportados.
O cliente deve iniciar a descoberta a partir de issuer previamente confiável e verificar que o issuer publicado no documento corresponde exatamente ao esperado. Não deve aceitar um issuer fornecido livremente pelo usuário e, a partir dele, buscar sem política, pois isso permite , mix-up e confiança em provedores não autorizados.
jwks_uri publica chaves públicas. Bibliotecas armazenam e usam kid para selecionar a chave. A rotação exige período de sobreposição: assinados com chave anterior ainda podem estar válidos enquanto a nova chave já é publicada. Em falha de kid, o cliente pode atualizar o de forma controlada, evitando loops de rede causados por maliciosos.
reduz configuração manual, mas não transforma qualquer em confiável. O issuer raiz deve vir de configuração, allowlist ou cadeia de federação validada; redirects e jwks_uri continuam sujeitos a restrições de rede e política.
17.17 Registro de clientes e redirect
O OP precisa conhecer cada cliente: client_id, tipo de aplicação, redirect , -logout redirect , métodos de autenticação, chaves, e políticas. Clientes públicos não conseguem manter segredo confiável; clientes confidenciais precisam proteger credenciais e preferir autenticação assimétrica quando o risco justificar.
Redirect devem ser exatas e usar , exceto exceções controladas para loopback de aplicativos nativos. Custom schemes exigem proteção contra colisão e preferência por app links ou universal links quando disponíveis. Curingas e prefix matching amplos podem permitir que o seja entregue a destino controlado por atacante.
Registro dinâmico pode automatizar ecossistemas, mas amplia a superfície administrativa. Software statements, políticas, autenticação do registrante, validação de e lifecycle management tornam-se necessários. Em ambientes corporativos comuns, registro governado por catálogo e oferece maior previsibilidade.
Tabela 7 - A classificação do cliente determina controles possíveis, não apenas o nome do aplicativo.
Tipo de cliente
de credencial
Recomendação
Web server /
Pode proteger segredo ou chave no servidor
Code + e autenticação forte no .
no navegador
Não possui segredo confiável
Code + ; reduzir no browser e avaliar .
Aplicativo nativo
Usa armazenamento do sistema, mas é cliente público
Code + com browser externo e redirect seguro.
Daemon confidencial
Pode usar chave, certificado ou identidade de workload
Credentials para ; somente quando há usuário.
Figura 6 - Federação depende de uma cadeia explícita de , chaves, políticas e governança.
17.18 Federação de identidade e cadeia de confiança
Federação permite que uma aplicação confie na autenticação realizada por outro domínio. Em uma relação bilateral, o RP configura diretamente issuer, , chaves e regras. Em federações multilaterais, entidades e trust anchors podem publicar statements assinados e políticas que permitem resolver a cadeia de confiança de forma escalável.
A confiança técnica não substitui acordo organizacional. É necessário definir onboarding, ownership, assurance, resposta a incidentes, rotação de chaves, disponibilidade, privacidade, semântica de e desligamento. Um OP pode emitir criptograficamente válidos e ainda fornecer atributos incompatíveis com a política do RP.
OpenID Federation 1.0 formaliza trust chains e policies para ecossistemas com muitas entidades. A adoção deve considerar maturidade de produtos, perfil setorial e necessidade real. Em uma empresa com poucos issuers, configuração explícita pode ser mais simples; em ecossistemas governamentais, financeiros ou de saúde, federação multilateral pode reduzir acordos bilaterais.
17.19 Multi-tenant, múltiplos issuers e account linking
Aplicações multi-tenant podem aceitar usuários de múltiplos diretórios. A validação precisa determinar o issuer autorizado para cada tenant e impedir que uma chave válida de um tenant autentique identidades em outro. “common” ou equivalentes facilitam descoberta inicial, mas o final deve ser associado ao issuer concreto e à política de tenancy.
Account linking conecta identidades federadas a uma conta local. O processo deve exigir uma sessão já autenticada e uma nova prova no segundo provedor, com proteção contra e confirmação clara. Vincular automaticamente contas porque possuem o mesmo e-mail permite account takeover quando domínios ou endereços são reciclados.
Em migrações, preserve o histórico entre issuer antigo, antigo e nova identidade por tabela de mapeamento governada. de auditoria precisam registrar qual identidade federada foi usada, qual conta local resultou do linking e quem autorizou a associação.
Regra multiemissor
Nunca escolha a chave de validação apenas pelo kid sem antes fixar o issuer confiável. O mesmo kid pode existir em domínios diferentes, e de um issuer não devem validar de outro.
17.20 Aplicações web, , e aplicativos nativos
Aplicações web com podem manter e credenciais no servidor e expor ao navegador apenas um de sessão protegido. Esse modelo reduz a superfície de exfiltração por JavaScript, mas exige proteção contra , fixação de sessão, roubo de e problemas de escalabilidade do estado.
SPAs são clientes públicos. com substitui o implicit flow como abordagem moderna, mas continuam acessíveis ao contexto do navegador se armazenados no front-end. Content Security Policy, redução de dependências, proteção contra , curtos e armazenamento cuidadoso são necessários. O padrão transfere o tratamento de ao servidor e oferece ao browser uma sessão restrita à origem.
Aplicativos nativos devem usar navegador externo ou sessão de autenticação do sistema, não webview embutida que capture credenciais. Redirects usam app links, universal links ou loopback conforme plataforma. é obrigatório em prática moderna, e devem ser rotacionados e armazenados no mecanismo seguro do sistema quando suportado.
Tabela 8 - O fluxo é semelhante, mas o local de execução muda o modelo de ameaça.
Arquitetura
Onde ficam os
Risco dominante
Web server
do cliente
Sessão, , credencial do cliente e acesso ao servidor.
Contexto do navegador
, extensão maliciosa e persistência de .
; browser recebe
, sessão do e confiança no .
Aplicativo nativo
do dispositivo
Malware, redirect hijacking e dispositivo comprometido.
17.21 em , Axway e
Um pode atuar como para autenticar usuários de portal ou console, como em arquiteturas específicas ou como PEP que valida emitidos pelo mesmo ecossistema. Esses papéis devem ser configurados separadamente. Validar no de uma não corrige o erro de usar o errado; a continua precisando de destinado à sua audiência.
No Axway , filtros e serviços permitem atuar como provider ou , criar e validar e integrar fluxos . O desenho deve separar políticas de login interativo das políticas de proteção de , manter stores e certificados governados e validar issuer, audience, e conforme o papel exercido.
No , aplicações registradas recebem client_id, redirect e configurações de . O normalmente protege validando com validate- ou validate--ad-. A política pode usar OpenID configuration para obter issuer e chaves, mas deve exigir audience e adequadas; a simples validação criptográfica não substitui autorização.
Em portais de desenvolvedores e consoles administrativos, pode fornecer . Para chamadas runtime, o deve preservar a identidade do usuário e da aplicação de forma controlada, remover externos equivalentes e, quando necessário, emitir ou obter credencial adequada para o .
A aplicação cliente valida o e mantém a sessão do usuário. O protege validando e aplicando políticas. Misturar essas responsabilidades produz audiences erradas e exposição desnecessária de .
17.22 Ameaças e hardening
injection ocorre quando um code obtido em outra transação é inserido no do cliente. state, ,, validação de issuer e regras de mix-up reduzem o risco. Redirect aberta ou registro flexível permite desvio do code. pode roubar em SPAs, enquanto pode acionar ou logout em contexto indevido.
substitution ocorre quando um ou válido para outro cliente, issuer ou propósito é aceito. A defesa é validação estrita de issuer, audience, , tipo e contexto. Algoritmos inesperados, chaves obtidas de indicada pelo e global de kid criam falhas criptográficas e multiemissor.
Login associa a sessão da vítima à conta do atacante, fazendo a vítima operar sob identidade errada. State por transação, correlação de sessão e confirmação de conta reduzem o risco. Account linking automático por e-mail é outra forma de confusão de identidade.
Logout também possui ameaças: redirecionamento aberto, limpeza parcial, de logout e negação de sessão. post_logout_redirect_uri deve ser registrado; logout precisam de assinatura, audience, eventos, jti e tempo; devem ser idempotentes e limitar abuso.
Tabela 9 - seguro depende de vínculos entre transações, emissores, clientes e artefatos.
Ameaça
Erro de implementação
Controle principal
Mix-up de issuer
Processar resposta sem fixar OP esperado
Issuer por transação, confiável e validação exata.
Code injection
Aceitar code sem vínculo à tentativa
, state, e correlacionado.
substitution
Aceitar de outra audience ou tipo
aud, , typ, issuer e finalidade do .
Login
Criar sessão com resposta não iniciada pelo usuário
state forte e registro de transação.
em
acessíveis a script comprometido
, CSP, redução de scripts e curto.
Account linking indevido
Vincular por e-mail coincidente
Reautenticação nos dois lados e confirmação explícita.
Logout
Aceitar logout repetido ou antigo
jti, exp/iat, assinatura e idempotência.
17.23 orientado por evidências
O diagnóstico deve separar front-channel, , validação do , criação de sessão e acesso à . Um erro no pode ser state divergente, redirect incorreta ou code expirado. Um erro no pode ser authentication, , reutilização do code ou relógio. Um login bem-sucedido seguido de 401 na normalmente aponta para ausente, audience errada ou policy do .
Colete correlation ID, issuer esperado, client_id, redirect normalizada, response_type, , timestamps, kid, algoritmo, audiences e resultado de cada validação. Nunca registre completos, authorization codes, code_verifiers, secrets ou . Para análise, use sintéticas ou irreversíveis controlados.
Problemas intermitentes após rotação de chaves podem indicar de , nós com relógio divergente ou ausência de sobreposição. Falhas somente em um tenant sugerem issuer, consentimento, ou política de tenancy. Logout que funciona em uma aplicação e não em outra deve ser analisado por tipo de canal, /, registrado e estado local do RP.
Tabela 10 - Sintomas devem ser associados à etapa exata do fluxo.
Sintoma
Hipóteses prioritárias
Evidência
invalid_state
Transação perdida, bloqueado, duplicado
state emitido, recebido e sessão correlacionada.
invalid_grant no
Code expirado/reusado, redirect ou verifier divergente
Tempo, redirect e do verifier.
Assinatura inválida
kid novo, issuer errado, de
, atual e relógio.
Audience inválida
emitido para outro client_id
aud, e client_id configurado.
inválido
Resposta de outra tentativa ou
armazenado por transação.
Login funciona, retorna 401
ausente, expirado ou audience errada
Authorization e policy do .
Logout parcial
Mecanismo não propagado ou RP não limpou sessão
/, e de logout.
Checklist de telemetria sem exposição de credenciais
Registro seguro de diagnóstico:
- transaction_id e correlation_id
- issuer esperado e client_id
- redirect_uri normalizada
- state_match, nonce_match e pkce_result
- alg, kid, aud, azp e tempos sem token bruto
- sessão criada, renovada ou invalidada
- código de erro do OP e etapa que respondeu
17.24 Estudos de caso
Caso 1 - aceito pela
Um portal envia o no Authorization para o . O possui assinatura válida e aud igual ao client_id do portal, não à . O foi configurado para verificar apenas assinatura e expiração, portanto aceita a chamada. O passa a confiar em um destinado a outro componente e sem de recurso.
A correção é solicitar para a audience da , validar issuer, audience, tipo e no e manter o apenas no cliente. A migração deve observar consumidores existentes e impedir que ambos os tipos sejam aceitos indefinidamente.
Caso 2 - Falha intermitente após rotação de chave
O OP começa a assinar novos com outro kid, mas um nó da aplicação mantém em por período excessivo. Alguns usuários recebem com a chave nova e falham; outros continuam autenticando com antigos. Reiniciar o nó parece corrigir temporariamente.
O diagnóstico compara kid, nó de atendimento e idade do . A solução inclui com refresh controlado em kid desconhecido, sobreposição de chaves pelo emissor, observabilidade e biblioteca atualizada. Não se deve buscar de chave fornecida pelo .
Caso 3 - Account takeover por linking automático
Uma aplicação vincula automaticamente uma nova identidade federada à conta local quando o e-mail coincide. Um domínio libera um endereço antigo, que é atribuído a outra pessoa. O novo titular autentica no OP e recebe acesso à conta histórica.
A correção exige + como identidade, processo explícito de linking com reautenticação e confirmação, alertas ao usuário e trilha de auditoria. E-mail permanece atributo de contato, não prova de continuidade da identidade.
Caso 4 - Logout fecha o portal, mas não encerra outras aplicações
O portal limpa seu e chama o de logout do OP, porém outro RP mantém sessão local ativa. A expectativa de “logout global” não estava documentada e o OP não enviava front-channel ou .
O desenho é revisado para registrar de back-channel, emitir , validar logout e definir comportamento de indisponibilidade. A interface passa a distinguir “sair deste aplicativo” de “encerrar sessão corporativa”.
Laboratórios de observação
Laboratório 1 - fluxo completo
Use um provedor e cliente de laboratório autorizados.
Capture a authorization sem registrar credenciais reais.
Identifique state, , code_challenge, code e .
Valide o com biblioteca e compare , aud, e tempo.
Laboratório 2 - matriz de validação
Crie sintéticos ou fixtures assinadas com chave de laboratório.
Teste issuer errado, audience errada, expiração, divergente e alg não permitido.
Registre qual validação rejeitou cada .
Confirme que o cliente não cria sessão após qualquer falha.
Laboratório 3 - e minimização
Solicite openid, profile e email em ambiente de teste.
Compare do e do .
Valide que é igual nas duas respostas.
Reduza e observe quais dados deixam de ser entregues.
Laboratório 4 - sessão e logout
Crie duas RPs de laboratório sob o mesmo OP.
Observe e diferencie do OP e das RPs.
Teste logout local, RP-Initiated e, se suportado, back-channel.
Registre quais sessões permanecem ativas em cada cenário.
Laboratório 5 - rotação de
Publique duas chaves de laboratório e altere a chave ativa.
Observe , kid e aceitação de antigos.
Teste refresh controlado em kid desconhecido.
Defina janela de sobreposição e alertas de falha.
Resumo do capítulo
acrescenta autenticação interoperável ao . O openid ativa o protocolo, e o comunica ao um evento de autenticação. O continua destinado à . Confundir os dois artefatos é uma falha de arquitetura, ainda que ambos sejam .
O Flow com utiliza state, e code_verifier para proteger relações diferentes. O cliente valida issuer, assinatura, algoritmo, audience, , tempo, e requisitos de assurance antes de criar sessão. como , e auth_time são úteis apenas quando sua semântica é conhecida.
entrega autorizadas e precisa manter o mesmo do . A identidade federada deve ser persistida por + ; e-mail não é chave imutável. Public e pairwise subjects oferecem diferentes propriedades de correlação e privacidade.
Sessão no OP, sessão no RP e perante são estados independentes. Logout exige política explícita e pode usar RP-Initiated, Front-Channel ou Back-Channel. e facilitam configuração e rotação, mas o issuer raiz e a cadeia de confiança precisam ser controlados.
Em , protege login de portais e aplicações, enquanto normalmente exigem . Axway e oferecem recursos para e validação, mas configuração de audience, e autorização continua responsabilidade da arquitetura.
Próximo passo do curso
O Capítulo 18 aprofundará ,, e : serialização, algoritmos, key identifiers, , rotação, validação, criptografia de e armadilhas de implementação.
Checklist de
O openid está presente somente em fluxos de autenticação .
O cliente utiliza com e redirect exata.
state, e code_verifier são únicos por transação e removidos após uso.
O issuer é configurado ou resolvido por cadeia de confiança autorizada.
A assinatura é validada com algoritmo permitido e chave do correto.
aud e são comparados ao client_id esperado.
exp, iat e auth_time usam relógio sincronizado e tolerância limitada.
O permanece no cliente e não substitui da .
é comparado ao do .
A conta federada usa + , não e-mail, como chave externa.
e possuem semântica documentada por issuer.
de OP e RP têm proteção, expiração e política de renovação.
Logout local, RP-Initiated, front-channel e back-channel têm comportamento definido.
e possuem , refresh controlado e proteção de rede.
Multi-tenant valida issuer concreto e política de tenancy.
não armazenam , codes, secrets, verifiers ou .
Bibliotecas são mantidas atualizadas e testadas com casos negativos.
Exercícios
Explique por que não é, isoladamente, um protocolo de login.
Diferencie OP, RP, Authorization Server e Resource Server.
Descreva o papel de openid, state, e .
Liste as validações obrigatórias de um .
Explique quando precisa ser analisado.
Compare , e resposta .
Explique por que + é melhor que e-mail para account linking.
Compare public e identifiers.
Modele step-up usando max_age, auth_time e .
Diferencie sessão no OP, sessão no RP e validade de .
Compare RP-Initiated, Front-Channel e .
Descreva como lidar com rotação de sem reiniciar aplicações.
Proponha uma política multi-tenant que evite mix-up de issuer.
Explique por que o deve validar , não .
Crie um roteiro de para invalid_state e invalid_grant.
Glossário
Tabela 11 - Vocabulário essencial do capítulo.
Termo
Definição
Authentication Context Class Reference; classe de contexto de autenticação.
Authentication Methods References; métodos utilizados na autenticação.
Instante em que ocorreu a autenticação ativa do usuário.
Artefato curto trocado no .
Authorized Party; cliente autorizado quando aud contém múltiplos valores.
Logout direto do OP para o do RP.
que vincula ao em fluxos aplicáveis.
Mecanismo para obter do .
Pessoa autenticada pelo .
Logout propagado pelo navegador entre OP e RPs.
destinado ao RP para comunicar o evento de autenticação.
Issuer; identificador do emissor do .
Conjunto de chaves públicas para validação criptográfica.
Idade máxima aceitável da autenticação.
Valor que vincula solicitação de autenticação e .
Entidade que autentica o usuário e emite .
diferente por setor de clientes para reduzir correlação.
Parâmetro que controla interação como none, login ou consent.
reutilizado entre clientes conforme política do issuer.
Cliente que confia na autenticação do OP.
Solicitação de logout iniciada pelo cliente.
Identificador de sessão usado em mecanismos de logout.
Subject Identifier; identificador do usuário no issuer.
protegido que retorna autorizadas do usuário.
Anexo A - Matriz de arquitetura
Tabela 12 - A escolha depende de plataforma, risco, experiência e capacidade do provedor.
Cenário
Arquitetura inicial
Controles essenciais
Aplicação web corporativa
Code + com sessão server-side
authentication, seguro, , e logout.
de baixo risco
Code +
CSP, curto, sem secret e proteção .
de maior risco
+ Code +
no , HttpOnly e .
Aplicativo nativo
Code + com browser externo
app/universal link, armazenamento seguro e refresh rotation.
Portal multi-tenant
Issuer por tenant e policy explícita
aud/, tenancy, consent e account linking seguro.
Operação com step-up
Nova authorization com assurance
,, e vínculo à operação.
com logout corporativo
Sessão OP + RP-Initiated + back-channel
, logout , idempotência e observabilidade.
Federação multilateral
OpenID Federation ou perfil setorial
trust anchors, policies e governança.
Referências técnicas
OpenID Foundation. Core 1.0 incorporating errata set 2.
OpenID Foundation. 1.0 incorporating errata set 2.
OpenID Foundation. 1.0. 2022.
OpenID Foundation. 1.0. 2022.
OpenID Foundation. 1.0, com errata incorporada. 2023.
OpenID Foundation. Management 1.0. 2022.
OpenID Foundation. OpenID Federation 1.0. 2026.
. 6749 - The Authorization . 2012.
. 7636 - Proof Key for Code Exchange by Public Clients. 2015.
. 7519 - Web . 2015.
. 8414 - Authorization Server . 2018.
. 8252 - for Native Apps. 2017.
. 8725 - Web Best Current Practices. 2020.
. 9207 - Authorization Server Issuer Identification. 2022.
. 9700 - Best Current Practice for Security. 2025.
Microsoft Learn. Microsoft identity platform and protocol.
Microsoft Learn. validate- e validate--ad- policies.
Axway Documentation. and ; filters.
. Security Cheat Sheet e Management Cheat Sheet.
Nota de atualização
é um conjunto de especificações e perfis em evolução. Antes de implantar , logout, federação ou de assurance, confirme a versão suportada pelo provedor, pela biblioteca e pelo . Internet-Drafts e extensões proprietárias não substituem automaticamente especificações finais.
