DocumentaçãoSuporteCosta Rica · Contato
ESENPT
Fale conosco
  • Técnica

OAuth 2.0

Em poucas palavras

OAuth 2.0 é o padrão da internet que permite a uma pessoa autorizar um aplicativo a acessar seus dados em outro serviço sem entregar sua senha. Na saúde, é a base com que pacientes e profissionais autorizam apps a consultar prontuários, sinistros ou resultados. Ele autoriza o acesso; sozinho, não identifica a pessoa.

Tipo
Padrão
Responsável
IETF — Internet Engineering Task Force
Versão vigente
RFC 6749
Revisado
25 de outubro de 2026

Explicação

O que é

OAuth 2.0 é um arcabouço de autorização publicado pela IETF como RFC 6749 em outubro de 2012. Permite que um aplicativo obtenha acesso limitado a um serviço HTTP, seja em nome do seu dono (a pessoa), seja em nome próprio. Em vez de compartilhar credenciais, o cliente recebe um token de acesso com permissões e validade limitadas.

Como funciona

O RFC define quatro papéis:

  • Dono do recurso: normalmente, o paciente ou o profissional.
  • Cliente: o aplicativo que quer acessar.
  • Servidor de autorização: autentica a pessoa, pede seu consentimento e emite os tokens.
  • Servidor de recursos: a API que guarda os dados, por exemplo um servidor FHIR.

Há diferentes concessões (grants) para obter um token. Na saúde, destacam-se o código de autorização, com participação da pessoa (o que usam o SMART App Launch e o Blue Button 2.0), e as credenciais de cliente, para processos entre sistemas. O uso de tokens portadores (bearer) é definido no RFC 6750.

Situação atual

O OAuth 2.0 foi atualizado por documentos posteriores. Os mais relevantes:

  • RFC 7636 (2015), PKCE, que protege a troca do código de autorização.
  • RFC 9700 (janeiro de 2025), boas práticas de segurança: os clientes não deveriam usar a concessão implícita, e a concessão com senha do usuário não deve ser usada. Além disso, clientes públicos devem usar PKCE.

O OAuth 2.1 reúne essas práticas em um só texto, mas em 25 de outubro de 2026 ainda é um rascunho da IETF (versão 16, de setembro de 2026), não um RFC.

Equívocos comuns

  • OAuth não é um protocolo de autenticação. Um token de acesso não diz quem é o usuário; para isso existe o OpenID Connect.
  • «Usamos OAuth» não basta como requisito de segurança. Importam a concessão escolhida, o uso de PKCE, a validade dos tokens e as permissões concedidas.
  • A concessão implícita está no RFC 6749, mas o RFC 9700 a desaconselha; o Blue Button 2.0, por exemplo, não a aceita.
  • O OAuth não define quais dados um app pode ver. Isso é fixado pelos escopos (scopes) de cada API, como os do SMART App Launch no FHIR.

Exemplos de uso

  1. O SMART App Launch, guia da HL7 para autorizar apps sobre APIs FHIR, define todos os seus padrões como perfis do OAuth 2.0.

  2. A API Blue Button 2.0 do CMS usa a concessão de código de autorização com clientes confidenciais e exige PKCE; não aceita a concessão implícita.

  3. Com o endpoint /revoke do Blue Button 2.0, um app revoga o token e a autorização de acesso que um beneficiário do Medicare lhe havia concedido.

  4. Um processo de backend obtém um token com a concessão de credenciais de cliente, autenticando-se com um JWT assinado, conforme o SMART Backend Services.

  5. O perfil IUA (Internet User Authorization) da IHE usa tokens de acesso OAuth para autorizar transações REST em saúde.

Relação com outros termos

Apoia-se em0

Este termo não se apoia em outros do glossário.

Dependem deste3

  • OpenID ConnectObrigatória

    O OpenID Connect é uma camada de identidade sobre o OAuth 2.0 e reutiliza seus fluxos e endpoints.

  • SMART App LaunchObrigatória

    Todos os padrões de autorização do SMART são perfis do OAuth 2.0.

  • Gestão do consentimentoMédia

    O perfil IHE PCF reutiliza as transações de tokens de acesso do IHE IUA, que se baseia em OAuth; o registro do consentimento não precisa dele.

Fontes

  1. RFC 6749 — The OAuth 2.0 Authorization Frameworkrfc-editor.org
  2. RFC 6750 — The OAuth 2.0 Authorization Framework: Bearer Token Usagerfc-editor.org
  3. RFC 7636 — Proof Key for Code Exchange (PKCE)rfc-editor.org
  4. RFC 9700 — Best Current Practice for OAuth 2.0 Securityrfc-editor.org
  5. IETF Datatracker — The OAuth 2.1 Authorization Framework (Internet-Draft)datatracker.ietf.org
  6. HL7 — SMART App Launch Implementation Guidehl7.org
  7. CMS — Blue Button 2.0 API: Authorizationbluebutton.cms.gov
  8. IHE ITI — Internet User Authorization (IUA)profiles.ihe.net
Glossário de interoperabilidade em saúde