DocumentaciónSoporteCosta Rica · Contacto
ESENPT
Hablemos
  • Técnica

OAuth 2.0

En pocas palabras

OAuth 2.0 es el estándar de internet que permite a una persona autorizar a una aplicación a acceder a sus datos en otro servicio sin entregarle su contraseña. En salud, es la base con la que pacientes y profesionales autorizan apps a consultar historias clínicas, reclamaciones o resultados. Autoriza el acceso; por sí solo no identifica a la persona.

Tipo
Estándar
Responsable
IETF — Internet Engineering Task Force
Versión vigente
RFC 6749
Revisado
25 de octubre de 2026

Explicación

Qué es

OAuth 2.0 es un marco de autorización publicado por la IETF como RFC 6749 en octubre de 2012. Permite que una aplicación obtenga acceso limitado a un servicio HTTP, ya sea en nombre de su dueño (la persona) o en nombre propio. En lugar de compartir credenciales, el cliente recibe un token de acceso con permisos y vigencia acotados.

Cómo funciona

El RFC define cuatro roles:

  • Dueño del recurso: normalmente, el paciente o el profesional.
  • Cliente: la aplicación que quiere acceder.
  • Servidor de autorización: autentica a la persona, pide su consentimiento y emite los tokens.
  • Servidor de recursos: la API que guarda los datos, por ejemplo un servidor FHIR.

Para obtener un token existen distintas concesiones (grants). En salud destacan el código de autorización, con intervención de la persona (el que usan SMART App Launch y Blue Button 2.0), y las credenciales de cliente, para procesos entre sistemas. El uso de tokens portadores (bearer) se define en el RFC 6750.

Estado actual

OAuth 2.0 se actualizó con documentos posteriores. Los más relevantes:

  • RFC 7636 (2015), PKCE, que protege el intercambio del código de autorización.
  • RFC 9700 (enero de 2025), buenas prácticas de seguridad: los clientes no deberían usar la concesión implícita y la concesión con contraseña del usuario no debe usarse. Además, los clientes públicos deben usar PKCE.

OAuth 2.1 reúne esas prácticas en un solo texto, pero al 25 de octubre de 2026 sigue siendo un borrador de la IETF (versión 16, de septiembre de 2026), no un RFC.

Errores frecuentes

  • OAuth no es un protocolo de autenticación. Un token de acceso no dice quién es el usuario; para eso existe OpenID Connect.
  • «Usamos OAuth» no basta como requisito de seguridad. Importan la concesión elegida, el uso de PKCE, la vigencia de los tokens y los permisos concedidos.
  • La concesión implícita aparece en el RFC 6749, pero el RFC 9700 la desaconseja; Blue Button 2.0, por ejemplo, no la admite.
  • OAuth no define qué datos puede ver una app. Eso lo fijan los ámbitos (scopes) de cada API, como los de SMART App Launch en FHIR.

Ejemplos de uso

  1. SMART App Launch, la guía de HL7 para autorizar apps sobre APIs FHIR, define todos sus patrones como perfiles de OAuth 2.0.

  2. La API Blue Button 2.0 de CMS usa la concesión de código de autorización con clientes confidenciales y exige PKCE; no admite la concesión implícita.

  3. Con el endpoint /revoke de Blue Button 2.0, una app revoca el token y la autorización de acceso que le había concedido un beneficiario de Medicare.

  4. Un proceso de backend obtiene un token con la concesión de credenciales de cliente, autenticándose con un JWT firmado, según SMART Backend Services.

  5. El perfil IUA (Internet User Authorization) de IHE usa tokens de acceso de OAuth para autorizar transacciones REST en salud.

Relación con otros términos

Se apoya en0

Este término no se apoya en otros del glosario.

Dependen de este3

  • OpenID ConnectObligatoria

    OpenID Connect es una capa de identidad sobre OAuth 2.0 y reutiliza sus flujos y endpoints.

  • SMART App LaunchObligatoria

    Todos los patrones de autorización de SMART son perfiles de OAuth 2.0.

  • Gestión del consentimientoMediana

    El perfil IHE PCF reutiliza las transacciones de tokens de acceso de IHE IUA, que se basa en OAuth; el registro del consentimiento no lo necesita.

Fuentes

  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
Glosario de interoperabilidad en salud