アカウントリンクロール

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

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

1. 認可サーバー

2. リソース所有者 (エンドユーザー）

3. リソースサーバー

4. クライアント

以下に、これらの 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) による認可コードフローもサポートしています。

認可サーバーは次のいずれかである必要があります。

• JWT トークンなど、抽出可能なエンドユーザーまたはリソース所有者 ID を含むアクセストークンを発行する

• 発行された各アクセストークンのエンドユーザー ID を返すことができる

そうしないと、コネクタは必要なAWS.ActivateUserオペレーションをサポートできなくなります。これにより、マネージド統合でのコネクタの使用が防止されます。

コネクタ開発者または所有者が独自の認可サーバーを維持していない場合、使用する認可サーバーはコネクタ開発者のサードパーティープラットフォームによって管理されるリソースの認可を提供する必要があります。つまり、認可サーバーからマネージド統合によって受信されるトークンは、デバイス (リソース) に意味のあるセキュリティ境界を提供する必要があります。たとえば、エンドユーザートークンは別のエンドユーザーデバイスでのコマンドを許可しません。トークンによって提供されるアクセス許可は、プラットフォーム内のリソースにマッピングされます。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" リソースサーバーを介して、ユーザーに代わって照明をオンまたはオフにすることが含まれます。したがって、コネクタをクライアントとして指定します。