DocumentationSupportCosta Rica · Contact
ESENPT
Let’s talk
  • Technical

OAuth 2.0

In short

OAuth 2.0 is the internet standard that lets a person authorize an application to access their data in another service without handing over their password. In healthcare, it is the basis for patients and clinicians authorizing apps to read health records, claims or results. It authorizes access; on its own it does not identify the person.

Type
Standard
Steward
IETF — Internet Engineering Task Force
Current version
RFC 6749
Reviewed
October 25, 2026

Explanation

What it is

OAuth 2.0 is an authorization framework published by the IETF as RFC 6749 in October 2012. It lets an application obtain limited access to an HTTP service, either on behalf of its owner (the person) or on its own behalf. Instead of sharing credentials, the client receives an access token with limited permissions and lifetime.

How it works

The RFC defines four roles:

  • Resource owner: usually the patient or the clinician.
  • Client: the application that wants access.
  • Authorization server: authenticates the person, asks for consent and issues tokens.
  • Resource server: the API that holds the data, for example a FHIR server.

There are several grants for obtaining a token. In healthcare, the key ones are the authorization code grant, with the person involved (used by SMART App Launch and Blue Button 2.0), and client credentials, for system-to-system processes. Bearer token usage is defined in RFC 6750.

Current status

OAuth 2.0 has been updated by later documents. The most relevant:

  • RFC 7636 (2015), PKCE, which protects the authorization code exchange.
  • RFC 9700 (January 2025), security best practices: clients should not use the implicit grant, and the resource owner password credentials grant must not be used. Public clients must also use PKCE.

OAuth 2.1 consolidates those practices into a single text, but as of 25 October 2026 it is still an IETF draft (version 16, September 2026), not an RFC.

Common misconceptions

  • OAuth is not an authentication protocol. An access token does not say who the user is; that is what OpenID Connect is for.
  • "We use OAuth" is not enough as a security requirement. The chosen grant, PKCE, token lifetime and granted permissions all matter.
  • The implicit grant is in RFC 6749, but RFC 9700 discourages it; Blue Button 2.0, for example, does not support it.
  • OAuth does not define what data an app can see. That is set by each API's scopes, such as SMART App Launch scopes in FHIR.

Usage examples

  1. SMART App Launch, the HL7 guide for authorizing apps on FHIR APIs, defines all its patterns as profiles of OAuth 2.0.

  2. The CMS Blue Button 2.0 API uses the authorization code grant with confidential clients and requires PKCE; it does not support the implicit grant.

  3. Using the Blue Button 2.0 /revoke endpoint, an app revokes the token and the data access grant a Medicare enrollee had given it.

  4. A backend process obtains a token with the client credentials grant, authenticating with a signed JWT, as defined by SMART Backend Services.

  5. The IHE IUA (Internet User Authorization) profile uses OAuth access tokens to authorize RESTful health transactions.

Relation to other terms

Relies on0

This term does not rely on other glossary terms.

Depend on this one3

  • OpenID ConnectRequired

    OpenID Connect is an identity layer on top of OAuth 2.0 and reuses its flows and endpoints.

  • SMART App LaunchRequired

    Every SMART authorization pattern is a profile of OAuth 2.0.

  • Consent managementMedium

    The IHE PCF profile reuses the access token transactions of IHE IUA, which is based on OAuth; recording consent does not need it.

Sources

  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
Health interoperability glossary