📚 Glossário do Reino OIDC

👥 Para Leigos:

É como um passe VIP temporário que permite entrar em áreas específicas de um evento. Você não precisa mostrar seu documento de identidade toda vez - apenas o passe.

🎭 No Reino OIDC:

Ace Token - O Guerreiro das Permissões
É o guerreiro corajoso que carrega sua espada (permissões) e tem vida limitada. Depois de um tempo, ele precisa descansar e um novo guerreiro assume o posto.

🔧 Para Técnicos:

String opaca ou JWT que representa uma autorização para acessar recursos protegidos. Tem escopo limitado e tempo de vida curto (15-60 min).

💻 Exemplo:

Authorization: Bearer eyJhbGciOiJSUzI1NiIs...

🎯 Usado para:

• Acessar APIs protegidas
• Validar permissões (scopes)
• Autenticação stateless

👥 Para Leigos:

É o processo de provar quem você é. Como quando você mostra seu RG na entrada de um prédio para comprovar sua identidade.

🎭 No Reino OIDC:

Dama Authen - A Verificadora Real
Ela é a responsável por verificar se você é realmente quem diz ser. Usa sua lupa mágica para examinar suas credenciais.

🔧 Para Técnicos:

Processo de verificar a identidade de um usuário, normalmente através de credenciais como username/password, biometria, ou fatores múltiplos.

🔄 Métodos comuns:

• Something you know: senha, PIN
• Something you have: celular, token
• Something you are: biometria

⚖️ Diferença importante:

Authentication ≠ Authorization
Autenticação = "Quem é você?"
Autorização = "O que você pode fazer?"

👥 Para Leigos:

É decidir o que você pode fazer depois que sua identidade foi confirmada. Como um funcionário do hotel que, após verificar seu check-in, te dá as chaves dos quartos que você pode acessar.

🎭 No Reino OIDC:

Lady OAuth - A Distribuidora de Permissões
Após Dama Authen confirmar quem você é, Lady OAuth decide quais portas você pode abrir e quais tesouros pode acessar no reino.

🔧 Para Técnicos:

Processo de determinar as permissões de um usuário autenticado. Define quais recursos podem ser acessados e que operações podem ser executadas.

🎯 Implementações comuns:

• RBAC: Role-Based Access Control
• ABAC: Attribute-Based Access Control
• ACL: Access Control Lists
• Scopes: No contexto OAuth

💻 Exemplo OAuth:

scope: "read:posts write:comments"

👥 Para Leigos:

É como um cupom de troca temporário. Você ganha este cupom após fazer login, mas ele não vale nada sozinho - precisa ser trocado por algo útil (como tokens) em uma loja específica.

🎭 No Reino OIDC:

Código Secreto de Alex Client
É uma senha temporária que Alex recebe após você fazer login. Ele usa essa senha para buscar seus tokens verdadeiros no cofre de Lady OAuth.

🔧 Para Técnicos:

String temporária e opaca retornada pelo authorization server após autenticação bem-sucedida. Deve ser trocada por tokens no endpoint /token.

⏱️ Características:

• Vida útil: 10 minutos (máximo)
• Uso único: Invalidado após troca
• Vinculado: client_id + redirect_uri
• Não exposição: Nunca vai para o browser

🔄 Fluxo típico:

1. User → /authorize → Login
2. Server → code=abc123 → Client
3. Client → POST /token + code → Tokens

👥 Para Leigos:

São informações sobre você que estão "carimbadas" no seu documento digital. Como os dados no seu RG: nome, data de nascimento, etc.

🎭 No Reino OIDC:

Segredos gravados no medalhão de IDA Token
IDA carrega um medalhão mágico onde estão gravadas informações sobre você: seu nome real, título, missões que pode realizar, quando seu passe expira.

🔧 Para Técnicos:

Key-value pairs dentro de um JWT que fornecem informações sobre o usuário ou contexto de autenticação.

🏷️ Claims padrão (OIDC):

• sub: Subject (ID único do usuário)
• name: Nome completo
• email: Endereço de email
• aud: Audience (quem pode usar)
• exp: Expiration time
• iat: Issued at time

💻 Exemplo:

{
  "sub": "user123",
  "name": "João Silva",
  "email": "joao@example.com",
  "exp": 1672531200
}

👥 Para Leigos:

É o aplicativo ou site que você está usando. Como o app do banco no seu celular ou o site da loja online. Ele precisa "conversar" com outros sistemas para funcionar.

🎭 No Reino OIDC:

Alex Client - O Mensageiro Confiável
É o mensageiro que trabalha para você. Quando você quer acessar algo, Alex vai até Lady OAuth pedir permissão em seu nome e traz de volta os tokens necessários.

🔧 Para Técnicos:

Aplicação que solicita autorização em nome do usuário para acessar recursos protegidos. Registrada no Authorization Server com client_id único.

🏷️ Tipos de Client:

• Public: SPA, mobile (sem client_secret)
• Confidential: Server-side (com client_secret)
• Native: Apps instalados no dispositivo

📋 Configuração típica:

{
  "client_id": "myapp123",
  "redirect_uris": ["https://app.com/callback"],
  "grant_types": ["authorization_code"],
  "response_types": ["code"]
}

👥 Para Leigos:

É como um balcão específico em uma repartição pública. Cada balcão tem uma função: um para tirar RG, outro para pagar multas, outro para informações. Cada um tem seu endereço.

🎭 No Reino OIDC:

Os Portais Sagrados de Lord OIDC
São as diferentes portas do castelo: a Porta da Autorização (/authorize), a Câmara dos Tokens (/token), o Espelho das Informações (/userinfo).

🔧 Para Técnicos:

URL específica que aceita requisições HTTP para operações do protocolo OAuth/OIDC. Cada endpoint tem função e parâmetros específicos.

🚪 Endpoints principais:

• /authorize: Inicia fluxo de autorização
• /token: Troca códigos por tokens
• /userinfo: Retorna dados do usuário
• /.well-known/openid-configuration: Metadados
• /jwks.json: Chaves públicas

💻 Exemplo:

GET https://auth.example.com/authorize?
response_type=code&client_id=app123

👥 Para Leigos:

É como uma carteira de identidade digital que prova quem você é. Diferente do Access Token (que é como um passe), este documento fala sobre você: seu nome, quando nasceu, etc.

🎭 No Reino OIDC:

IDA Token - A Mensageira da Verdade
Ela carrega um pergaminho oficial assinado por Lord OIDC que conta quem você é. Ninguém pode falsificar esse pergaminho porque tem o selo mágico do reino.

🔧 Para Técnicos:

JWT assinado que contém claims sobre a autenticação do usuário. Específico do OpenID Connect, sempre no formato JWT.

🔑 Claims obrigatórios:

• iss: Issuer (quem emitiu)
• sub: Subject (ID do usuário)
• aud: Audience (para quem é)
• exp: Expiration time
• iat: Issued at time

⚠️ Importante:

NÃO enviar em APIs! ID Token é para o client verificar a autenticação, não para autorizar acesso a recursos.

💻 Estrutura:

eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJ1c2VyMTIzIn0.signature

👥 Para Leigos:

É quem você é - como seu nome, sobrenome, onde nasceu, seu e-mail. São as informações que te identificam de forma única no mundo digital.

🎭 No Reino OIDC:

Sire Identi - O Registrador do Reino
Ele mantém os livros sagrados com informações sobre todos os cidadãos: nomes verdadeiros, títulos, origem, características que tornam cada pessoa única no reino.

🔧 Para Técnicos:

Conjunto de atributos únicos que descrevem uma entidade (usuário, aplicação, dispositivo). Base para autenticação e autorização.

🏷️ Componentes típicos:

• Identificador único: UUID, email, username
• Atributos pessoais: nome, sobrenome, telefone
• Atributos organizacionais: departamento, cargo
• Preferências: idioma, timezone

🔐 Identity vs Authentication:

• Identity: "Eu sou João Silva"
• Authentication: "Prove que você é João"

👥 Para Leigos:

É como um documento oficial com três partes: o cabeçalho (que tipo de documento é), o conteúdo (suas informações) e a assinatura (para provar que é verdadeiro).

🎭 No Reino OIDC:

Os Pergaminhos Mágicos
São documentos especiais com três seções: o selo de identificação, o conteúdo com seus dados, e a assinatura mágica que ninguém pode falsificar.

🔧 Para Técnicos:

Padrão aberto (RFC 7519) para transmitir informações de forma segura entre partes. Formato: header.payload.signature

📋 Estrutura:

• Header: Algoritmo e tipo (Base64URL)
• Payload: Claims/dados (Base64URL)
• Signature: Assinatura criptográfica

✅ Vantagens:

• Auto-contido (não precisa consultar BD)
• Stateless
• Padrão da indústria
• Suporte amplo

💻 Exemplo:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIn0.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

👥 Para Leigos:

É um sistema de permissões que permite que um app acesse suas informações em outro serviço sem você dar sua senha. Como dar uma chave temporária para alguém entrar na sua casa.

🎭 No Reino OIDC:

Lady OAuth - A Guardiã das Portas
Ela decide quem pode entrar e o que pode fazer no reino. Dá permissões temporárias sem que você precise entregar suas chaves principais (senhas).

🔧 Para Técnicos:

Framework de autorização que permite acesso limitado a recursos HTTP sem expor credenciais. OAuth 2.1 consolida boas práticas da versão 2.0.

🆕 Principais mudanças na versão 2.1:

• PKCE obrigatório para todos os clients
• Implicit Flow removido
• Resource Owner Password removido
• Redirect URI exato (sem wildcards)
• Refresh Token rotation recomendado

🎯 Foco:

OAuth é sobre AUTORIZAÇÃO (o que você pode fazer), não autenticação (quem você é).

👥 Para Leigos:

É um sistema de identidade que funciona sobre OAuth. Enquanto OAuth diz "o que você pode fazer", OIDC diz "quem você é". Como um RG digital padronizado.

🎭 No Reino OIDC:

Lord OIDC - O Mago da Identidade
Ele trabalha junto com Lady OAuth. Enquanto ela cuida das permissões, ele cuida da identidade - criando carteiras de identidade mágicas (ID Tokens) para todos.

🔧 Para Técnicos:

Camada de identidade construída sobre OAuth 2.0. Adiciona autenticação padronizada e informações de identidade via ID Token.

➕ O que OIDC adiciona ao OAuth:

• ID Token: JWT com claims de identidade
• UserInfo endpoint: Dados adicionais do usuário
• Scope "openid": Ativa recursos OIDC
• Claims padronizados: sub, name, email, etc.
• Discovery: /.well-known/openid-configuration

🔄 Fluxo básico:

1. Client → /authorize?scope=openid
2. User autentica
3. Client recebe: Access Token + ID Token
4. Client valida ID Token → identidade confirmada

👥 Para Leigos:

É um sistema de segurança extra que funciona como dar metade de uma senha para alguém e guardar a outra metade. Só quando as duas partes se juntam é que funciona.

🎭 No Reino OIDC:

Pixie PKCE - A Guardiã dos Códigos Secretos
Uma fada protetora que sempre acompanha Alex Client. Ela cria pares de chaves mágicas que impedem que ladrões roubem códigos no caminho.

🔧 Para Técnicos:

Extensão de segurança OAuth (RFC 7636) que protege contra ataques de interceptação de código de autorização. Obrigatório no OAuth 2.1.

🔑 Como funciona:

1. Client gera code_verifier (segredo)
2. Client calcula code_challenge = SHA256(verifier)
3. Envia challenge para /authorize
4. Troca código + verifier no /token
5. Server valida: SHA256(verifier) = challenge

🛡️ Protege contra:

• Interceptação de código de autorização
• Ataques CSRF
• Malware no dispositivo

💻 Parâmetros:

code_challenge=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
code_challenge_method=S256

👥 Para Leigos:

É como uma "renovação automática". Quando seu passe VIP expira, ao invés de você ter que fazer toda a fila de novo, você tem um cupom especial que renova tudo automaticamente.

🎭 No Reino OIDC:

Rex Token - O Renovador Eterno
Ele vive nas sombras, sempre vigilante. Quando Ace Token fica cansado, Rex aparece silenciosamente e troca os tokens, renovando tudo sem que você perceba.

🔧 Para Técnicos:

Credential de longa duração usado para obter novos access tokens sem re-autenticação do usuário. Mais sensível que access token.

🔄 Refresh Token Rotation:

1. Access token expira
2. Client usa refresh token
3. Server retorna: novo access + novo refresh
4. Refresh token antigo é invalidado

🛡️ Boas práticas:

• Armazenamento seguro (httpOnly cookies)
• Rotação a cada uso
• Detecção de reutilização
• Vida útil limitada (dias/semanas)

💻 Uso:

POST /token
grant_type=refresh_token&refresh_token=abc123

👥 Para Leigos:

É o guardião dos seus dados. Como um funcionário de banco que só libera informações da sua conta se você mostrar um documento válido (token).

🎭 No Reino OIDC:

Seraph Resource - O Guardião dos Dados
É o guerreiro angelical que protege os tesouros do reino. Ele só abre os cofres quando alguém apresenta um token válido assinado por Lady OAuth.

🔧 Para Técnicos:

Servidor HTTP que hospeda recursos protegidos. Aceita e valida access tokens para autorizar acesso a APIs.

🔍 Responsabilidades:

• Validar access tokens (assinatura, expiração)
• Verificar scopes e permissões
• Proteger recursos HTTP
• Retornar dados autorizados

🔐 Validação típica:

1. Extrair token do header Authorization
2. Verificar assinatura JWT
3. Validar claims (exp, aud, scope)
4. Autorizar acesso ao recurso

💻 Exemplo header:

Authorization: Bearer eyJhbGciOiJSUzI1NiIs...

👥 Para Leigos:

São as permissões específicas que você está dando para um app. Como dizer: "pode ver minhas fotos, mas não pode deletar" ou "pode ler meus emails, mas não pode enviar".

🎭 No Reino OIDC:

Cartas de Permissão de Lady OAuth
São pergaminhos específicos que Lady OAuth escreve definindo exatamente o que cada visitante pode fazer: "ler na biblioteca", "entrar no jardim", "falar com o rei".

🔧 Para Técnicos:

Strings que definem permissões específicas que o client está solicitando. Limitam o que pode ser feito com o access token.

🏷️ Scopes OIDC padrão:

• openid: Obrigatório para OIDC (ativa ID Token)
• profile: Nome, sobrenome, nickname, etc.
• email: Endereço de email
• address: Endereço físico
• phone: Número de telefone

💡 Scopes personalizados:

• read:posts - Ler postagens
• write:comments - Escrever comentários
• admin:users - Administrar usuários

💻 Exemplo de requisição:

scope=openid profile email read:posts

👥 Para Leigos:

É quando você faz login uma vez e pode usar vários apps diferentes sem ter que digitar senha novamente. Como ter uma chave mestra que abre várias portas.

🎭 No Reino OIDC:

A Magia da Entrada Única
Uma vez que você passa pela Grande Porta de Lady OAuth e Lord OIDC, ganha um amuleto mágico que abre todas as outras portas do reino federado.

🔧 Para Técnicos:

Capacidade de um usuário se autenticar uma vez e acessar múltiplos sistemas sem re-autenticação. OIDC facilita implementação de SSO.

🔄 Como funciona com OIDC:

1. User autentica no Identity Provider
2. Sessão é criada no IdP
3. Outras apps redirecionam para mesmo IdP
4. IdP verifica sessão existente
5. Retorna tokens sem nova autenticação

✅ Benefícios:

• UX melhorada: Login uma vez
• Segurança: Credenciais centralizadas
• Administração: Controle centralizado

🔐 Implementação:

Usar parâmetro prompt=none para verificação silenciosa de sessão.