App 詢問授權 - App asks for authorization

出處:http://docs.smarthealthit.org/authorization/

At launch time, the app constructs a request for authorization by adding the following parameters to the query component of the EHR’s "authorize" endpoint URL using the "application/x-www-form-urlencoded" format:

Parameters
`response_type`	required	Fixed value: `code`.
`client_id`	required	The client's identifier.
`redirect_uri`	required	Must match one of the client's pre-registered redirect URIs.
`launch`	optional	When using the EHR launchflow, this must match the launch value received from the EHR.
`scope`	required	Must describe the access that the app needs, including clinical data scopes like `patient/*.read`, `openid` and `profile` (if app needs authenticated patient identity) and either: a `launch` value indicating that the app wants to receive already-established launch context details from the EHR a set of launch context requirements in the form `launch/patient`, which asks the EHR to establish context on your behalf. See SMART on FHIR Access Scopes details.
`state`	required	An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The parameter MUST be used for preventing cross-site request forgery or session fixation attacks.
`aud`	required	URL of the EHR resource server from which the app wishes to retrieve FHIR data. This parameter prevents leaking a genuine bearer token to a counterfeit resource server. (Note: in the case of an EHR launch flow, this `aud` value is the same as the launch's `iss` value.)

The app MUST use an unpredictable value for the state parameter with at least 128 bits of entropy. The app MUST validate the value of the state parameter upon return to the redirect URL and MUST ensure that the state value is securely tied to the user’s current session (e.g., by relating the state value to a session identifier issued by the app). The app SHOULD limit the grants, scope, and period of time requested to the minimum necessary.

If the app needs to authenticate the identity of the end-user, it should include two OpenID Connect scopes: openid and profile. When these scopes are requested, and the request is granted, the app will receive an id_token along with the access token. For full details, see SMART launch context parameters.

For example

An app that needs demographics and observations for a single patient, and also wants information about the current logged-in user, the app can request:

patient/Patient.read
patient/Observation.read
openid profile

If the app was launched from an EHR, the app adds a launch scope and a launch={launch id} URL parameter, echoing the value it received from the EHR to bind to the EHR context of this launch notification.

Apps using the standalone launch flow won't have a launch id at this point. These apps can declare launch context requirements by adding specific scopes to the authorization request: for example, launch/patient to indicate that you need to know a patient ID, or launch/encounter to indicate you need an encounter. The EHR's "authorize" endpoint will take care of acquiring the context you need (and then making it available to you). For example, if your app needs patient context, the EHR may provide the end-user with a patient selection widget. For full details, see SMART launch context parameters.

The app then redirects the browser to the EHR's authorization URL as determined above:

Location: https://ehr/authorize?
            response_type=code&
            client_id=app-client-id&
            redirect_uri=https%3A%2F%2Fapp%2Fafter-auth&
            launch=xyz123&
            scope=launch+patient%2FObservation.read+patient%2FPatient.read+openid+profile&
            state=98wrghuwuogerg97&
            aud=https://ehr/fhir