アカウントリンクの構成要素
Alexa Skills Kit（ASK）では、AlexaユーザーのAmazonアカウントとサービスの既存アカウントのリンク作成に、OAuth 2.0認証フレームワークを使用します。OAuth 2.0は、ユーザーが以前に設定したアカウントから、ユーザーの権限を使ってAlexaが情報にアクセスできるようにする方法を定義します。
このトピックでは、最も一般的なAlexaスキルへのアカウントリンクの実装である Authorization code grant種別を使ったAlexaアプリのみのアカウントリンクにおける、OAuth 2.0の構成要素について説明します。Implicit grantやアプリ間アカウントリンクといったあまり一般的ではないアカウントリンクの方法についてはここでは説明しませんが、構成要素には共通する部分が多数あります。
アカウントリンクの概要
システム内のユーザーのアカウントにアクセスするには、Alexaスキルに「アクセストークン」が必要です。アカウントリンクは、これらのアクセストークンを取得するためのユーザーの権限を取得するプロセスです。ユーザーがこの権限を付与すると、スキルはサーバーへのAPI呼び出しでトークンを使用してユーザーデータにアクセスします。
Authorization code grant種別と呼ばれる最も一般的なアプローチでは、Alexaサービスは2段階のプロセスに従います。まず、認可コードを取得します。次に、このコードをアクセストークンと交換し、オプションで更新トークンと交換します。これにより、元のアクセストークンの有効期限が切れたときにAlexaが新しいアクセストークンをリクエストできるようになります。
以下の図は、このトピックで後述するアカウントリンクの主要コンポーネントの関係を示しています。ここでは、自社でユーザーデータを含むサーバーを所有していることを前提として説明します。ただし、サードパーティのサーバーを使用することも可能です。ユーザーから見たエクスペリエンスの例については、Alexaスキルにおけるユーザーのアカウントリンク体験を参照してください。
構成要素
以下は、アカウントリンクを実装する際に使用する構成要素です。
OAuthのロール
OAuth 2.0では、リソースオーナー、リソースサーバー、クライアント、認可サーバーという4つのロールを定義しています。以下のセクションでは、Alexaスキルにおけるこれらのロールについて説明します。例では、ユーザーが配車を依頼するカスタムスキル（「タクシー予約」）と照明を制御するスマートホームスキル（「マイライト」）という架空のスキルを使います。
リソースオーナー
スキルを有効にしてシステムアカウントにリンクするAlexaユーザーです。
リソースサーバー
Alexaスキルがユーザーの権限でアクセスするのに必要な、保護されたリソース（ユーザーデータ）をホストします。
クライアント
ユーザーの権限を使い、Alexaユーザーに代わってリソースサーバーにリクエストを送信するAlexaスキルです。
スキルがOAuthクライアントであっても、Alexaはスキルに代わって一部の操作を行います。たとえば、Alexaは認可サーバーに対してアクセストークンを取得するリクエストを行います。その場合でも、リソースサーバーにある保護されたリソース（ユーザーデータ）にアクセスするコンポーネントはスキルのみであるため、スキルはクライアントとみなされます。
認可サーバー
AlexaユーザーのIDを識別し、システムのユーザーに対して認証します。サーバーは次の機能を実行するため、アカウントリンクには不可欠です。
- システムにログインするためのログインページをユーザーに表示する。
- システム内のユーザーを認証する。
- ユーザーを識別する認可コードを生成する。
- 認可コードをAlexaアプリに渡す。
- Alexaサービスからの認可コードを受け入れ、Alexaサービスがシステム内のユーザーのデータにアクセスするために使用するアクセストークンを返す。
トークンの交換を処理するため、認可サーバーはトークンサーバーとも呼ばれます。
Login with Amazonなどのサードパーティの認可サーバーや独自の認可サーバーを使用できます。どちらの場合も、OAuth 2.0をサポートしている必要があります。サードパーティの認可サーバーを使う場合、認可サーバーはリソースサーバーのユーザーにマッピングできるデータを提供します。たとえば、Login with Amazonを使用してユーザーを認証する場合、Amazonのprofile:user_idを使ってデータベースのユーザープロファイルにアクセスします。
認証画面のURI要件については、認証画面のURI要件を参照してください。
コードとトークン
Alexaスキルにおけるアカウントリンクでは、リソース（サービスのユーザーアカウントなど）へのアクセスにアクセストークンを使用します。Authorization code grant種別のシナリオでは、クライアントはまず認可コードを取得し、取得したコードをアクセストークンと交換する必要があります。また、古いアクセストークンの有効期限が切れたときに新しいアクセストークンをリクエストできるように、更新トークンを取得することもできます。
アカウントリンクは以下のコードとトークンをサポートします。
認可コード
Authorization code grant種別の場合、認可サーバーがAlexaサービスに認可コードを付与し、Alexaサービスはこのコードをアクセストークンと更新トークンのペアと交換します。ユーザーが認可サーバーにログインすると、認可サーバーはユーザーをAlexaアプリにリダイレクトする際のクエリ文字列に認可コードを含めることで、Alexaサービスに認可コードを渡します。
アクセストークン
アクセストークンは、Alexaサービスがユーザー認証時に提供された認可コードを交換するときにトークンサーバーから提供される認証情報です。アクセストークンと更新トークンのペアは、システムのユーザーを識別し、Alexaスキルがシステムのユーザーデータにアクセスするためのユーザーの権限を表します。ユーザーがアカウントを正常にリンクできている場合、Alexaサービスがトークンサーバーからアクセストークンを取得した後は、このアクセストークンがスキルに送信されるリクエストに含まれるようになります。
アクセストークンURIの要件については、アクセストークンURIの要件を参照してください。
更新トークン
古いアクセストークンの有効期限が切れた後、Alexaサービスが新しいアクセストークンをリクエストするのに使用する認証情報です。
相互アクセストークン
相互アクセストークンは相互認可に使用されます。相互認可により、ユーザーはリソースのペア（Alexaに使用するAmazonアカウントとサービスに使用するアカウントなど）を2つのアカウント間で同期し、更新することができます。
Grant種別
OAuth 2.0では、Grant種別を定義しています。Grantとは、Alexaスキルがユーザーを認証してアクセストークンを取得するための方法です。このトークンにより、スキルはリソースサーバーに対して認証されたリクエストを行うことができます。Alexaスキルに適用されるGrant種別には、最も一般的なAuthorization code grantと限定的な用途に使用されるImplicit grantの2つがあります。Amazonでは、セキュリティと使いやすさの理由から、Authorization code grant種別を推奨しています。Alexaアカウントリンクのドキュメントでは、Authorization code種別に焦点を当てています。
Authorization code grant種別
このGrant種別では、コードとトークンで説明したとおり、Alexaサービスが認可サーバーから認可コードを取得し、取得したコードをアクセストークンと交換して、スキルへのリクエストでアクセストークンを渡します。Authorization code grantでは、ユーザーが認可サーバーにログインした後、認可サーバーがユーザーをAlexaアプリにリダイレクトする際のクエリ文字列に認可コードを含めることで、Alexaサービスに認可コードを渡します。Alexaサービスはこのコードとアクセストークンのエンドポイント（URI）を使用して、アクセストークンと更新トークンのペアをトークンサーバーにリクエストします。アクセストークンの期限が切れると、Alexaサービスは更新トークンを使って新しいアクセストークンをリクエストします。どうしてもImplicit grant種別を使う必要ある場合を除き、Authorization code grant種別を実装してください。
Implicit grant種別
他のシステム内のユーザー情報にアクセスするためにユーザーの認可をリクエストするGrant種別です。Implicit grantでは、ユーザーがログインに成功すると認可サーバーがアクセストークンを返します。このGrant種別は、Authorization code grant種別ほど安全ではありません。Implicit grant種別を使用できるのはカスタムスキルのみです。
相互認可
ユーザーがリソースペアを同期し、更新できる場合のことを相互認可と言います。通常のアカウントリンクでは、Alexaスキルがシステムのリソースにアクセスできます。相互認可では、さらに一歩進んで、ユーザーもAlexaリソースにアクセスできます。
ほとんどのOAuthサーバーでは、システムのユーザーを認証・認可する機能のみを提供しています。ただし、一部のスキルでは、Alexaバックエンドとプロアクティブに通信して更新を行う必要があります。この機能を実現するのが相互認可エンドポイントです。相互認可エンドポイントは、Alexaから認可コードを取得するために開発者がホストします。
アカウントリンクのURI
アカウントリンクでは以下のURIを使用します。Alexaは、URIのクエリ文字列としてパラメーターを認可サーバーに渡します。
| 名前 | 説明 | 指定と取得の方法 |
|---|---|---|
|
認証画面のURI |
認可サーバーのURIです。Alexaサービスに認可コードを提供します。Alexaサービスが認証画面のURIを呼び出す際に使用するクエリパラメーターの一覧は、こちらを参照してください。
|
URIの指定方法：
|
|
AlexaリダイレクトURI |
ユーザーがシステムにログインすると、認可サーバーはこのURIを呼び出してユーザーをAlexaアプリにリダイレクトします。 |
Alexaサービスが認証画面のURIを呼び出した際に AlexaリダイレクトURIは、開発者コンソール、ASK CLI、REST APIでも確認できます。ただし、これらのソースでは複数のリダイレクトURIが表示されます。最終的な値はユーザーがどのAlexaデバイスから登録したかによって異なるためです。そのため、Alexaがクエリパラメーターとして認証画面のURIに渡した 認証画面のURI要件の説明に従って、AlexaリダイレクトURIを登録する必要があります。 |
|
アクセストークンURI |
トークンサーバーのURI、つまり認可サーバーのエンドポイントです。認可サーバーは認可コードを受け取ってアクセストークンと更新トークンのペアをAlexaサービスに返し、Alexaサービスは受け取ったトークンのペアを使用してシステムのユーザーデータにアクセスします。Alexaサービスは、アクセストークンURIにPOSTリクエストを送信し、パラメーターに認可コードを含めます。トークンサーバーはこれに応答し、JSONにアクセストークンと更新トークンを含めます。
|
指定方法：
|
関連トピック
最終更新日: 2025 年 09 月 17 日