OAuth 2.0 authorization via SMART App Launch 2.0. Authenticate users, obtain patient context, and access FHIR resources with granular scopes — against a sandbox you can register an app on in about a minute.
Every SMART client starts at https://api.mock.health/fhir/.well-known/smart-configuration, which advertises the authorization and token endpoints, supported scopes, PKCE code challenge methods, and the capabilities array. If your client library reads this document, it will work here without special-casing.
Your app initiates the flow: redirect to the authorize endpoint with response_type=code, your client_id, redirect_uri, scope, state, aud, and a PKCE code_challenge. The user picks a patient, consents, and you exchange the code for an access token plus a patient context claim.
The EHR initiates: it opens your launch_uri with iss and launch parameters, and your app carries the opaque launch value back through the authorize request. Patient context arrives already resolved — no picker. This is how apps run inside Epic and Oracle Health in production, and it's the flow most sandboxes make hardest to rehearse.
SMART v2 granular scopes are supported: patient/Observation.rs, patient/*.r, user/Patient.r, system/*.r, plus launch, launch/patient, openid, fhirUser, and offline_access. A token is enforced against the scopes it was granted, so an over-broad request fails the way it will in production. Vendor-specific scope syntax is reproduced per deployment on the map — Oracle Health's .r/.rs/.rsu/.rsuc forms included.
Walk the whole thing end to end in the SMART on FHIR tutorial, test the launch inside a realistic portal with payer and provider portals, or check Inferno (g)(10) for the certification suite.