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

# アカウントリンクロール
<a name="roles-account-linking"></a>

C2C コネクタを作成するには、OAuth 2.0 認可サーバーとアカウントのリンクが必要です。詳細については、「[アカウントリンクワークフロー](account-linking-flow.md)」を参照してください。

OAuth 2.0 では、アカウントリンクを実装する際に次の 4 つのロールを定義します。

1. 認可サーバー

1. リソース所有者 (エンドユーザー)

1. リソースサーバー

1. クライアント

以下に、これらの OAuth ロールをそれぞれ定義します。

**認可サーバー**  
認可サーバーは、サードパーティークラウド内のエンドユーザーの ID を識別して認証するサーバーです。このサーバーによって提供されるアクセストークンは、 AWS エンドユーザーのカスタマープラットフォームアカウントとそのサードパーティープラットフォームアカウントをリンクできます。このプロセスはアカウントリンクと呼ばれます。  
認可サーバーは、以下を提供することでアカウントリンクをサポートします。  
+ エンドユーザーがシステムにログインするためのログインページを表示します。これは通常、認可エンドポイントと呼ばれます。
+ システム内のエンドユーザーを認証します。
+ エンドユーザーを識別する認可コードを生成します。
+ AWS IoT Device Management のマネージド統合に認可コードを渡します。
+ AWS IoT Device Management のマネージド統合から認可コードを受け取り、AWS IoT Device Management のマネージド統合がシステム内のエンドユーザーのデータにアクセスするために使用できるアクセストークンを返します。これは通常、トークン URI またはエンドポイントと呼ばれる別の URI を介して完了します。
認可サーバーは、AWS IoT Device Management Connector のマネージド統合で使用する OAuth 2.0 認可コードフローをサポートする必要があります。AWS IoT Device Management の マネージド統合は、コード[交換の証明キー (PKCE) による認可コード](https://www.rfc-editor.org/rfc/rfc7636)フローもサポートしています。  
認可サーバーは次のいずれかである必要があります。  
+ JWT トークンなど、抽出可能なエンドユーザーまたはリソース所有者 ID を含むアクセストークンを発行する
+ 発行された各アクセストークンのエンドユーザー ID を返すことができる
そうしないと、コネクタは必要な`AWS.ActivateUser`オペレーションをサポートできなくなります。これにより、マネージド統合でのコネクタの使用が防止されます。
コネクタ開発者または所有者が独自の認可サーバーを維持していない場合、使用する認可サーバーはコネクタ開発者のサードパーティープラットフォームによって管理されるリソースの認可を提供する必要があります。つまり、認可サーバーから Managed Integrations によって受信されるトークンは、デバイス (リソース) に意味のあるセキュリティ境界を提供する必要があります。たとえば、エンドユーザートークンは別のエンドユーザーデバイスでのコマンドを許可しません。トークンによって提供されるアクセス許可は、プラットフォーム内のリソースにマッピングされます。*Lights"* の例を考えてみましょう。エンドユーザーがコネクタとアカウントリンクフローを開始すると、認可サーバーの前にある* Lights"* ログインページにリダイレクトされます。ログインしてクライアントにアクセス許可を付与すると、コネクタに *Lights"* アカウント内のリソースへのアクセスを許可するトークンが提供されます。

**リソース所有者 (エンドユーザー)**  
リソース所有者は、アカウントリンクを実行して、AWS IoT Device Management の マネージド型統合に、アカウントに関連付けられたリソースへのアクセスを許可します。例えば、エンドユーザーが *Lights"* モバイルアプリケーションにオンボードしたスマート電球を考えてみましょう。リソース所有者とは、デバイスを購入してオンボーディングしたエンドユーザーアカウントを指します。この例では、リソース所有者は *Lights"* OAuth2.0 アカウントとしてモデル化されています。リソース所有者として、このアカウントはコマンドを発行し、デバイスを管理するためのアクセス許可を提供します。

**リソースサーバー**  
これは、 (デバイスデータ) へのアクセスの承認を必要とする保護されたリソースをホストするサーバーです。お客様は、エンドユーザーに代わって保護されたリソースにアクセス AWS する必要があり、AWS IoT Device Management コネクタのアカウントリンク後のマネージド統合を通じてアクセスします。以前からのスマート電球を例として考えた場合、リソースサーバーは *Lights"* が所有するクラウドベースのサービスであり、オンボーディング後に電球を管理します。リソースサーバーを通じて、リソース所有者はスマート電球のオン/オフなどのコマンドを発行できます。保護されたリソースは、エンドユーザーのアカウントと、エンドユーザーがアクセス許可を付与した可能性のある他のアカウント/エンティティにのみアクセス許可を提供します。

**クライアント**  
このコンテキストでは、クライアントは C2C コネクタです。クライアントは、エンドユーザーに代わってリソースサーバー内のリソースへのアクセスが付与されるアプリケーションとして定義されます。アカウントリンクプロセスは、コネクタ、クライアントを表し、サードパーティークラウド内のエンドユーザーのリソースへのアクセスをリクエストします。  
コネクタは OAuth クライアントですが、AWS IoT Device Management のマネージド統合はコネクタに代わってオペレーションを実行します。たとえば、AWS IoT Device Management のマネージド統合は、アクセストークンの取得を認可サーバーにリクエストします。コネクタは、リソースサーバーの保護されたリソース (デバイスデータ) にアクセスする唯一のコンポーネントであるため、引き続きクライアントと見なされます。  
エンドユーザーによってオンボードされたスマート電球について考えてみましょう。顧客プラットフォームと *Lights" *認可サーバー間のアカウントリンクが完了すると、コネクタ自体がリソースサーバーと通信して、エンドユーザーのスマート電球に関する情報を取得します。その後、コネクタはエンドユーザーからコマンドを受信できます。これには、*Lights" *リソースサーバーを介して、ユーザーに代わって照明をオンまたはオフにすることが含まれます。したがって、コネクタをクライアントとして指定します。