Segurança Digital
OpenID Connect (OIDC)
OpenID Connect funciona como uma camada de identidade sobre OAuth 2.0: o cliente solicita o escopo `openid`, o provedor autentica o usuário e devolve um ID Token JWT com claims sobre a sessão. OIDC Core 1.0, com Errata Set 2 de 2023, define fluxos, validação, UserInfo e segurança; em 2025 foi publicado também como ITU‑T X.1285. Comparado a OAuth isolado, resolve autenticação padronizada. Integra Keycloak, Entra ID e Auth0, mas exige redirect URIs exatas, PKCE, validação de nonce, issuer e audiência.
🛡 Níveis de Segurança
Recomendado
Authorization Code Flow com PKCE
OpenID Connect é uma camada de autenticação sobre OAuth 2.0. O cliente, chamado Relying Party, redireciona o usuário para um OpenID Provider. A requisição inclui `client_id`, `redirect_uri`, `response_type=code`, `scope=openid`, `state`, `nonce` e, em clientes públicos, PKCE com `code_challenge`. O provedor autentica, obtém consentimento conforme política e devolve um authorization code para a redirect URI registrada. O cliente troca o code no token endpoint, apresentando `code_verifier` e autenticação de cliente quando confidencial. Recebe ID Token, access token e possivelmente refresh token. O ID Token é JWT assinado com claims como `iss`, `sub`, `aud`, `exp`, `iat`, `nonce`, `auth_time`, `acr` e `amr`. O cliente valida assinatura usando JWKS do issuer, `iss` exato, audiência/client ID, expiração e nonce igual. Se há múltiplas audiências, valida `azp` conforme regra. O code flow mantém tokens fora da URL do navegador e PKCE impede que um code interceptado seja trocado sem verifier. Em aplicativos móveis, usar navegador do sistema, não WebView embutida, e redirect por app link/universal link ou custom scheme protegido. Em SPA, uma arquitetura Backend for Frontend pode manter tokens no servidor e usar cookie seguro. Se a SPA recebe tokens, aplicar code+PKCE e minimizar armazenamento. O implicit flow é legado e não é a escolha moderna. Redirect URIs precisam ser exatas, sem curingas amplos. `state` liga resposta à sessão e reduz CSRF. `nonce` liga ID Token à requisição e reduz replay. São funções distintas. O cliente não deve usar access token para identificar usuário sem perfil. Usa ID Token e UserInfo.
Interoperabilidade
Discovery, JWKS e metadados confiáveis
OpenID Connect Discovery publica metadados em `/.well-known/openid-configuration` sob o issuer. O documento informa authorization endpoint, token endpoint, userinfo endpoint, `jwks_uri`, response types, subject types, algoritmos e recursos. Isso permite integrar Keycloak, Microsoft Entra ID, Auth0, Google e outros sem configurar cada URL manualmente. O issuer é a âncora. O cliente deve ter issuer confiável configurado ou um processo seguro de descoberta. Não aceitar issuer arbitrário vindo de parâmetro do usuário e buscar metadados internos, pois pode causar SSRF e trust confusion. O `issuer` nos metadados deve ser igual ao solicitado e ao `iss` do token. JWKS é obtido por HTTPS e cacheado. A rotação publica chave nova antes de assinar; o cliente atualiza ao ver `kid` desconhecido, com rate limit. Não buscar a cada requisição. Se o endpoint fica offline, usar cache válido por período. O cliente fixa algoritmos permitidos. A metadata pode anunciar. Não aceitar algoritmo fraco só porque anunciado. Dynamic Client Registration existe, mas não deve ser habilitado sem política; um atacante pode registrar redirects. Para plataformas de casa inteligente, discovery reduz configuração do painel com identidade corporativa ou familiar. Contudo, a dependência do IdP precisa de plano offline. Um hub pode manter contas locais de emergência. O login federado exige DNS, TLS e tempo corretos. Certificados e NTP. Se a Internet cai, sessões existentes podem continuar até expirar, mas novos logins podem falhar. O projeto deve declarar.
Privacidade
Claims, UserInfo e minimização de dados
OIDC comunica informações sobre o usuário por claims. `sub` é o identificador estável dentro do issuer e deve ser a chave principal. E-mail pode mudar e não deve identificar conta sozinho. `email_verified` indica verificação no contexto do provedor, mas não prova propriedade atual eterna. Nome e foto são apresentação. `preferred_username` pode não ser único. Subject types `public` e `pairwise` controlam correlação. Pairwise gera `sub` diferente por setor de clientes, reduzindo rastreamento. Uma plataforma residencial deve solicitar apenas `openid`, talvez `profile` e `email` se necessário. Não pedir telefone, endereço e grupos sem uso. Claims podem vir no ID Token ou UserInfo. O access token autoriza a chamada ao UserInfo. O cliente verifica que `sub` do UserInfo é igual ao ID Token. Não aceitar troca. Grupos e papéis são extensões de provedores, não núcleo universal. Um claim `roles` do Entra ou Keycloak precisa de mapeamento. O aplicativo não deve confiar em claim não documentada. A autorização da casa permanece no backend: associa `issuer+sub` a usuário, residências e permissões. O IdP autentica identidade, mas não sabe que a pessoa pode destravar a porta 2. SCIM ou grupos podem integrar, mas precisam de governança. Consentimento e privacidade. Tokens não entram em logs. O ID Token não é enviado a APIs como bearer. Access token é. Claims sensíveis não devem ser colocadas em JWT legível sem necessidade.
Evitar
Fluxos legados, redirects amplos e confusão OAuth/OIDC
OAuth 2.0 autoriza acesso; OIDC autentica o usuário. Um aplicativo que chama `/userinfo` com qualquer access token e assume identidade sem validar issuer, audiência e contexto pode aceitar token de outro cliente. O ID Token deve ser validado. Não usar access token de API como sessão de login quando o perfil não define. O implicit flow entregava tokens no fragmento e tinha riscos de vazamento; code flow com PKCE é preferido. Resource Owner Password Credentials não é OIDC e expõe senha ao cliente; evitar. Redirect URI com `https://app.example/callback/*` ou domínio controlável permite roubo de code. Registrar exato. Em mobile, custom schemes podem ser sequestrados por outro app; usar claimed HTTPS ou verificações de app. `state` previsível não protege. Gerar CSPRNG e vincular a cookie/sessão. `nonce` também aleatório. Não desativar validação de TLS para IdP interno. Use CA. Não aceitar tokens `alg=none`. Não usar client secret em SPA ou app mobile; é extraível. Clientes públicos usam PKCE. Client secrets em backend ficam em cofre e são rotacionados. Para maior segurança, usar private_key_jwt ou mTLS conforme provedor. Logout é complexo: encerrar sessão local, revogar refresh token e, se necessário, usar RP-Initiated Logout. Não presumir que logout local encerra SSO em outros apps.
🖥 Aplicações em Hardware
🔒
Home Assistant e painel
SSO por Keycloak, Authentik ou provedor corporativo
Um reverse proxy ou integração nativa usa OIDC code flow. O issuer é configurado fixamente. Redirect URI exata. O backend guarda client secret em cofre ou usa private_key_jwt. Cookies são Secure, HttpOnly e SameSite. O proxy não encaminha headers de identidade vindos do cliente; remove e reinsere após autenticação. O Home Assistant recebe usuário mapeado. Grupos mapeiam a funções, mas permissões de entidades são revisadas. MFA no IdP. Conta local de emergência. O proxy e IdP usam NTP e HTTPS. O logout encerra cookie local e redireciona ao endpoint quando desejado. Logs não guardam code ou token. Atualizações de proxy são acompanhadas.
🔒
Aplicativo móvel
Login de morador com navegador do sistema e PKCE
O app gera code verifier de alta entropia, challenge S256, state e nonce. Abre ASWebAuthenticationSession, Custom Tabs ou navegador do sistema. O usuário autentica com passkey/MFA. O redirect volta por universal link/app link validado. O app compara state, troca code com verifier e valida ID Token por biblioteca. Access e refresh tokens ficam no Keychain/Keystore com proteção. Refresh token é rotativo. O app não contém client secret. Em logout, apaga e revoga. Deep links maliciosos são testados. O app não aceita ID Token de outro issuer. O backend associa `iss+sub`. A versão do sistema pode. Não usar WebView que captura senha.
🔒
Cloud IoT
Federação de identidade para portal de fabricante
O portal atua como RP e aceita um conjunto de IdPs empresariais ou sociais. Cada issuer tem configuração. Para multi-tenant, não aceitar qualquer domínio sem onboarding. O tenant associa issuer. O backend verifica. O portal emite sua própria sessão após OIDC, em vez de propagar ID Token a todas as APIs. Access tokens internos têm audiência. Isso desacopla. O cadastro inicial precisa evitar account linking inseguro por e-mail. Vincular uma nova identidade exige usuário autenticado e reautenticação. Não juntar duas contas apenas porque o e-mail coincide. O provedor pode reciclar. `sub` é chave. Suporte precisa de processo. Logs de login ajudam. Risco de takeover é monitorado.
🔒
Gateway e controle de acesso
Step-up para ações críticas
Um gateway recebe sessão do portal, mas para destravar remotamente exige autenticação recente. Redireciona ao IdP com `max_age=0` ou política. O novo ID Token indica `auth_time` recente e método forte. O backend emite autorização de ação de 60 s, vinculada a usuário, casa, porta e nonce. O gateway executa uma vez. OIDC autentica; a autorização local decide. A fechadura mantém controle físico independente. Se o IdP está offline, o acesso remoto falha fechado, mas chave/PIN local funciona. O sistema registra evento. Não colocar comando de porta em ID Token. Não usar grupo `admins` como autorização universal. Políticas e auditoria.