OpenID Connect
Em poucas palavras
OpenID Connect é o padrão que permite a um aplicativo saber quem é o usuário, apoiando-se em um provedor de identidade confiável em vez de gerenciar suas próprias senhas. É o que torna possível entrar uma única vez e usar vários apps. Na saúde, serve para identificar pacientes e profissionais que acessam portais e aplicativos.
- Tipo
- Padrão
- Responsável
- OpenID Foundation
- Versão vigente
- Core 1.0 (errata set 2)
- Revisado
- 25 de outubro de 2026
Explicação
O que é
O OpenID Connect (OIDC) é, segundo sua especificação, «uma camada de identidade simples sobre o protocolo OAuth 2.0». É publicado pela OpenID Foundation; em outubro de 2026, a versão vigente é o OpenID Connect Core 1.0 com o conjunto de erratas 2 (15 de dezembro de 2023). Em 2024, o mesmo texto foi publicado também como norma internacional ISO/IEC 26131:2024.
Serve para que um aplicativo (a parte confiante, ou relying party) verifique a identidade de uma pessoa a partir da autenticação feita por um provedor OpenID (OpenID Provider) e obtenha dados básicos do seu perfil.
Como funciona
- O app inicia um fluxo OAuth 2.0 e inclui o escopo openid na solicitação.
- O provedor autentica a pessoa e devolve, além do token de acesso, um ID Token.
- O ID Token é um JSON Web Token (JWT) assinado, com afirmações (claims) sobre a autenticação. Deve incluir no mínimo o emissor (iss), o sujeito (sub), a audiência (aud), a expiração (exp) e o horário de emissão (iat).
- Com o token de acesso, o app pode consultar o endpoint UserInfo para obter mais dados do perfil.
Especificações complementares definem, por exemplo, a descoberta automática da configuração do provedor em /.well-known/openid-configuration.
Equívocos comuns
- OAuth 2.0 e OpenID Connect não são a mesma coisa. O OAuth autoriza o acesso a recursos; o OIDC acrescenta a identidade do usuário. Por isso um token de acesso não serve como prova de identidade.
- O app deve validar o ID Token (assinatura, emissor, audiência e validade) antes de confiar nele.
- Identificar a pessoa não é o mesmo que decidir a quais dados clínicos ela pode acessar. Isso é resolvido pelas permissões e políticas de cada sistema.
- A especificação tem muitas partes opcionais. Por isso os setores publicam perfis, como o perfil iGov para governos ou os requisitos do SMART App Launch na saúde.
Exemplos de uso
No SMART App Launch, um app pede os escopos openid e fhirUser para receber, junto com o ID Token, uma referência ao recurso FHIR que representa o usuário, como um Practitioner ou um Patient.
O NHS login, serviço de identidade de pacientes do NHS na Inglaterra, integra-se com o OpenID Connect 1.0 sobre o OAuth 2.0.
O Login.gov, serviço de login do governo federal dos EUA, suporta o OpenID Connect 1.0 e segue o perfil iGov.
A API Blue Button 2.0 do CMS aceita os escopos openid e profile para que o app consulte os dados do beneficiário no endpoint UserInfo.
Nos EUA, o CMS inclui o OpenID Connect Core 1.0 entre os padrões da Patient Access API que as operadoras abrangidas por suas regras de interoperabilidade devem oferecer.
Um hospital centraliza o login dos seus profissionais em um provedor OpenID, de modo que o portal clínico e os apps internos não guardam senhas próprias.
Relação com outros termos
Apoia-se em1
- OAuth 2.0Obrigatória
O OpenID Connect é uma camada de identidade sobre o OAuth 2.0 e reutiliza seus fluxos e endpoints.
Dependem deste1
- SMART App LaunchMédia
Só quando o app precisa saber quem é o usuário (capacidade sso-openid-connect, escopos openid e fhirUser).
Fontes
- OpenID Connect Core 1.0 incorporating errata set 2openid.net
- ISO/IEC 26131:2024 — OpenID Connect Core 1.0 incorporating errata set 2iso.org
- SMART App Launch — Scopes and Launch Contexthl7.org
- NHS England — NHS login (API and integration catalogue)digital.nhs.uk
- Login.gov — OpenID Connect developer guidedevelopers.login.gov
- CMS — Blue Button 2.0 API: Authorizationbluebutton.cms.gov
- CMS — APIs and relevant standards and implementation guidescms.gov