#2: SMART Access Token Format -- A Guided Walk Through FHIR скачать в хорошем качестве

#2: SMART Access Token Format -- A Guided Walk Through FHIR

We review a frequently asked question about the SMART App Launch Framework: what formats are used for an access token, and how are authorization details (expiration time, patient, scopes...) associated with an access token? We'll review the protocol design, which standardizes App/EHR communication, rather than EHR-internal communication; then we'll explore three techniques that EHR-internal components (Authorization Server + FHIR Resource Server) can use to communicate with each other: --- TL;DR. The OAuth Access Token response is sent from an Authorization Server to a Client Application, and includes an access token as well as several properties that the client can use to interpret that token. The token itself is opaque to the client; it's just a bearer token that that the client uses as part of an "Authorization" header for API requests to the Resource Server. However, it's very important that the Resource Server understands what these tokens mean, so it can correctly enforce the access rules. The mechanism by which the Resource Server learns these details is out of scope for the SMART App Launch Framework, but common approaches are: 1. Shared database, indexed by token. In this scheme, tokens are random strings stored in a database alongside their "context" or meaning (e.g., expiration time, scopes, patient restrictions, etc). 2. Signed token structures. In this scheme, tokens are structured, signed blobs that the Resource Server knows how to evaluate. A common approach is for the tokens to be signed (and optionally encrypted) JSON Web Tokens containing claims that convey the context (e.g., expiration time, scopes, patient restrictions, etc). 3. Token introspection API. In this scheme, the Authorization Server offers an API that the Resource Server can call to learn the context of a given token. The API takes the token as an input, and returns a set of context details as an output. These approaches are not exclusive; in theory a given Authorization server could support all three of these modes, for tighter/looser integration depending on the use case and the counterparty.