DocumentationSupportCosta Rica · Contact
ESENPT
Let’s talk
  • Technical

OpenID Connect

In short

OpenID Connect is the standard that lets an application know who the user is, relying on a trusted identity provider instead of managing its own passwords. It is what makes signing in once and using several apps possible. In healthcare, it is used to identify patients and clinicians who access portals and applications.

Type
Standard
Steward
OpenID Foundation
Current version
Core 1.0 (errata set 2)
Reviewed
October 25, 2026

Explanation

What it is

OpenID Connect (OIDC) is, in its specification's words, "a simple identity layer on top of the OAuth 2.0 protocol". It is published by the OpenID Foundation; as of October 2026, the current version is OpenID Connect Core 1.0 incorporating errata set 2 (15 December 2023). In 2024 the same text was also published as the international standard ISO/IEC 26131:2024.

It lets an application (the relying party) verify a person's identity based on the authentication performed by an OpenID Provider, and obtain basic profile information.

How it works

  • The app starts an OAuth 2.0 flow and includes the openid scope in the request.
  • The provider authenticates the person and returns, in addition to the access token, an ID Token.
  • The ID Token is a signed JSON Web Token (JWT) with claims about the authentication. It must include at least the issuer (iss), subject (sub), audience (aud), expiration (exp) and issued-at time (iat).
  • With the access token, the app can call the UserInfo endpoint to get more profile data.

Companion specifications define, for example, automatic discovery of the provider's configuration at /.well-known/openid-configuration.

Common misconceptions

  • OAuth 2.0 and OpenID Connect are not the same. OAuth authorizes access to resources; OIDC adds the user's identity. That is why an access token is not proof of identity.
  • The app must validate the ID Token (signature, issuer, audience and lifetime) before trusting it.
  • Identifying the person is not the same as deciding which clinical data they can access. That is handled by each system's permissions and policies.
  • The specification has many optional parts. That is why sectors publish profiles, such as the iGov profile for governments or the SMART App Launch requirements in healthcare.

Usage examples

  1. In SMART App Launch, an app requests the openid and fhirUser scopes to receive, along with the ID Token, a reference to the FHIR resource that represents the user, such as a Practitioner or a Patient.

  2. NHS login, the patient identity service of the NHS in England, integrates with OpenID Connect 1.0 on top of OAuth 2.0.

  3. Login.gov, the US federal government sign-in service, supports OpenID Connect 1.0 and conforms to the iGov profile.

  4. The CMS Blue Button 2.0 API accepts the openid and profile scopes so the app can read the beneficiary's data from the UserInfo endpoint.

  5. In the US, CMS lists OpenID Connect Core 1.0 among the standards for the Patient Access API that payers covered by its interoperability rules must offer.

  6. A hospital centralizes its clinicians' sign-in with an OpenID Provider, so the clinical portal and internal apps do not store their own passwords.

Relation to other terms

Relies on1

  • OAuth 2.0Required

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

Depend on this one1

  • SMART App LaunchMedium

    Only when the app needs to know who the user is (sso-openid-connect capability, openid and fhirUser scopes).

Sources

  1. OpenID Connect Core 1.0 incorporating errata set 2openid.net
  2. ISO/IEC 26131:2024 — OpenID Connect Core 1.0 incorporating errata set 2iso.org
  3. SMART App Launch — Scopes and Launch Contexthl7.org
  4. NHS England — NHS login (API and integration catalogue)digital.nhs.uk
  5. Login.gov — OpenID Connect developer guidedevelopers.login.gov
  6. CMS — Blue Button 2.0 API: Authorizationbluebutton.cms.gov
  7. CMS — APIs and relevant standards and implementation guidescms.gov
Health interoperability glossary