翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# SMART on FHIR の HealthLake 認証要件
<a name="reference-smart-on-fhir-authentication"></a>

SMART on FHIR 対応 HealthLake データストアの FHIR リソースにアクセスするには、クライアントアプリケーションが OAuth 2.0 準拠の認可サーバーによって承認され、FHIR REST API リクエストの一部として OAuth ベアラートークンを提示する必要があります。認可サーバーのエンドポイントを検索するには、Uniform Resource Identifier を介して FHIR Discovery Document の HealthLake SMART `Well-Known` を使用します。このプロセスについては、「[FHIR 検出ドキュメントの SMART の取得](reference-smart-on-fhir-discovery-document.md)」を参照してください。

SMART on FHIR HealthLake データストアを作成するときは、`CreateFHIRDatastore`リクエストの `metadata`要素で認可サーバーのエンドポイントとトークンエンドポイントを定義する必要があります。`metadata` 要素の定義の詳細については、「」を参照してください[HealthLake データストアの作成](managing-data-stores-create.md)。

認可サーバーエンドポイントを使用して、クライアントアプリケーションは認可サービスでユーザーを認証します。承認および認証されると、認可サービスによって JSON ウェブトークン (JWT) が生成され、クライアントアプリケーションに渡されます。このトークンには、クライアントアプリケーションが使用できる FHIR リソーススコープが含まれています。これにより、ユーザーがアクセスできるデータが制限されます。オプションで、起動スコープが指定されている場合、レスポンスにはそれらの詳細が含まれます。HealthLake でサポートされている FHIR スコープの SMART の詳細については、「」を参照してください[HealthLake でサポートされている FHIR OAuth 2.0 スコープでの SMART](reference-smart-on-fhir-oauth-scopes.md)。

認可サーバーによって付与された JWT を使用して、クライアントアプリケーションは FHIR が有効な HealthLake データストアで SMART への FHIR REST API 呼び出しを行います。JWT を検証してデコードするには、Lambda 関数を作成する必要があります。HealthLake は、FHIR REST API リクエストを受信すると、ユーザーに代わってこの Lambda 関数を呼び出します。スターター Lambda 関数の例については、「」を参照してください[を使用したトークンの検証 AWS Lambda](reference-smart-on-fhir-token-validation.md)。

## FHIR 対応 HealthLake データストアで SMART を作成するために必要な認可サーバー要素
<a name="datastore-auth-server"></a>

`CreateFHIRDatastore` リクエストでは、 `IdentityProviderConfiguration` オブジェクトの `metadata`要素の一部として認可エンドポイントとトークンエンドポイントを指定する必要があります。認可エンドポイントとトークンエンドポイントの両方が必要です。これを`CreateFHIRDatastore`リクエストで指定する方法の例については、「」を参照してください[HealthLake データストアの作成](managing-data-stores-create.md)。

## SMART on FHIR 対応 HealthLake データストアで FHIR REST API リクエストを完了するために必要なクレーム
<a name="server-response"></a>

 AWS Lambda 関数が SMART on FHIR 対応 HealthLake データストアでの有効な FHIR REST API リクエストであるためには、関数に次のクレームが含まれている必要があります。
+ `nbf`: [(前ではない) クレーム](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.5) — 「nbf」クレーム (前ではない) は、JWT を処理に受け入れることができない時刻を識別します。「nbf」クレームの処理では、現在の日付/時刻が「nbf」クレームに記載されている以前の日付/時刻以降である必要があります。提供されているサンプル Lambda 関数は、サーバーレスポンス`iat`から に変換します`nbf`。
+ `exp`: [(有効期限) クレーム — ](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.4)「有効期限」 (有効期限) クレームは、JWT を処理に受け入れてはならない 以降の有効期限を識別します。
+ `isAuthorized`: ブール値を に設定します`True`。認可サーバーでリクエストが承認されたことを示します。
+ `aud`: [(対象者) クレーム](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3) — 「aud」 (対象者) クレームは、JWT の対象となる受取人を識別します。これは、FHIR 対応 HealthLake データストアエンドポイントの SMART である必要があります。
+ `scope`: これは少なくとも 1 つの FHIR リソース関連のスコープである必要があります。このスコープは認可サーバーで定義されます。HealthLake で受け入れられる FHIR リソース関連のスコープの詳細については、「」を参照してください[HealthLake の FHIR リソーススコープに関する SMART](reference-smart-on-fhir-oauth-scopes.md#smart-on-fhir-scopes-rest)。