セッション外からAlexaを呼び出すためのユーザー固有のアクセストークンを取得する
カスタムスキルは、特定のAlexaリソースへのアクセスが常に必要な場合あります。たとえば、スキルがユーザーに通知を送信したり、ショッピングリストにアクセスしたり、デバイスの位置情報を読み取ったりする場合があります。これらのアクションは、スキルセッション外で発生する可能性があります。スキルセッション外でAlexa APIを呼び出すには、スキルがユーザー固有のAlexaアクセストークンを非同期で保存および更新する必要があります。
概要
はじめにスキルセッションについて復習し、スキルセッション外でスキルがAlexaリソースにアクセスする必要がある理由を説明します。スキルセッションは、次のように開始および終了します。
- スキルセッションは、ユーザーが「アレクサ、タクシー予約を開いて」などの発話でスキルを呼び出したときに開始されます。 これにより、Alexaはスキルにリクエストを送信します。このリクエストは通常起動リクエストですが、ユーザーは特定のインテントでスキルを呼び出すこともできます。リクエストには
session
オブジェクトが含まれており、これにはスキルセッションを一意に識別するsessionId
が含まれています。 - ユーザーがスキルを操作すると、Alexaはスキルリクエストを送信します。これらのリクエストには、前述の一意の
sessionId
が含まれます。スキルはリクエストに応答します。 - スキルセッションは、ユーザーがAlexaに応答しない場合、またはスキルが
shouldEndSession
をtrue
に設定してリクエストをAlexaに送信した場合に終了します。スキルセッションが終了すると、Alexaはその特定のsessionId
を持つスキルリクエストを送信しなくなります。ユーザーが新しいスキルセッションを呼び出すとsessionId
も新しいものになり、以前のスキルセッションは存在しません。
Alexaとスキルの間のほとんどのやり取りはスキルセッション内で発生しますが、ユーザーがスキルを明示的に呼び出さない場合でも、スキルがAlexaリソースにアクセスする必要がある場合があります。たとえば、ユーザーのショッピングリストを管理するスキルは、随時リストを更新する必要があります。これらのリクエストは、セッション外リクエストと呼ばれます。
セッション外リクエストの場合、スキルはユーザー固有のアクセストークンが必要となります。スキルはユーザー固有の認可コードを受け取ってから、ユーザー固有のアクセストークンを取得します。次に、スキルは一般的なOAuth 2.0認可コード付与フローで、認可コードとクライアント認証情報をアクセストークンに交換します。
スキルが認可コードをアクセストークンと正しく交換できない場合、ユーザーがスキルを有効にしたり同意を変更したりすると、Alexaはエラーを表示します。このような場合、Alexaはユーザーに認可を再試行するよう求めます。
認可コードを受け取るために使用するエンドポイントは、スキルがアカウントリンクを使用するかどうかによって異なります。
アカウントリンクを使用するスキルの場合
ユーザーがサードバーティサービスからAlexaスキルにアカウントリンクすると、ユーザーはAlexaがサービス内のアカウントリソースにアクセスすることを許可します。次に、Alexaは一般的なOAuth 2.0認可付与フローを通じてアクセストークンを保存および更新します。
しかし多くの場合、ユーザーは別のログインフローを経由することなく、Alexaリソースにアクセスするためのスキルも許可したいと考えています。これを相互認可といいます。
ステップ1: 認可コードを受け取る
Alexaは、以下のパラメーターを使用してエンドポイントに安全なHTTP POST application/x-www-form-urlencoded
リクエストを送信することで、認可コードを提供します。
エンドポイント
スキルは、スキルマニフェスト内のアカウントリンクスキーマで指定したreciprocalAccessTokenUrl
で認可コードを受け取ります。
リクエストのパラメーター
POSTリクエストには、次のパラメーターを含みます。
フィールド | 説明 |
---|---|
|
許可タイプ。値は |
|
ユーザーのAlexa認可コードです。 |
|
スキルのIDです。この |
例
認可コードを提供するリクエストの例を次に示します。
POST
Content-Type: application/x-www-form-urlencoded
Authorization: Bearer (3Pアクセストークン)
grant_type=reciprocal_authorization_code&code=EXAMPLEAUTHCODE1234&client_id=someClientId
ステップ2: 認可コードをアクセストークンと交換する
相互アクセストークンエンドポイントが認可トークンを受け取った後、相互アクセストークンエンドポイントは次のことを行う必要があります。
- 認可ヘッダー内の提供されたアクセストークンが有効であり、スキルのアカウントリンク設定で登録された認可サーバーのユーザーを表していることを確認します。
- 提供されたAlexa認可コードをAlexaアクセストークンと交換します。認可コードとアクセストークンの交換の詳細については、Login with Amazon(LWA)ドキュメントのアクセストークンリクエストを参照してください。
- 次のHTTPコードのいずれかを返します。
- 認可コードをアクセストークンと正常に交換した場合は
HTTP 200(OK)
を返します。 - 認可コードをアクセストークンと交換しようとしたときに問題が発生した場合は
HTTP 400(BAD_REQUEST)
を返します。 - その他の問題が生じた場合は
HTTP 500(INTERNAL_SERVER_ERROR)
を返します。
- 認可コードをアクセストークンと正常に交換した場合は
アカウントリンクを使用しないスキルの場合
スキルがアカウントリンクを必要としない場合は、セッション中のリクエストとAlexaイベントのsystem
オブジェクトからuserId
を使用してAlexaユーザーを識別できます。system
オブジェクトの詳細については、Systemオブジェクトを参照してください。
ステップ1: 認可コードを受け取る
Alexaは、以下のパラメータを使用してAlexa.Authorization.Grant
リクエストをエンドポイントに送信することで、認可コードを提供します。
エンドポイント
スキルは、スキルマニフェストのcustom
オブジェクトで指定したエンドポイントで認可コードを受け取ります。
スキル用に異なるリージョンのエンドポイントを設定している場合、Alexaは適切なリージョンのURIを呼び出します。
リクエストのパラメーター
リクエストには次のパラメータが含まれます。
フィールド | 説明 |
---|---|
|
リクエストタイプ。値は |
|
リクエストIDです。 |
|
リクエストのタイムスタンプです。 |
|
認可コードのタイプ。 |
|
ユーザーのAlexa認可コードです。 |
例
認可コードを提供するリクエストの例を次に示します。
{
"version": "1.0",
"context": {
"System": {
"application": {
"applicationId": "amzn1.ask.skill.aaa"
},
"user": {
"userId": "amzn1.ask.account.AAA"
},
"apiEndpoint": "https://api.amazonalexa.com"
},
"request": {
"type": "Alexa.Authorization.Grant",
"requestId": "12345-6789-EXAMPLE",
"timestamp": "2018-01-01T12:00:00Z",
"body" : {
"grant": {
"type": "OAuth2.AuthorizationCode",
"code": "EXAMPLEAUTHCODE1234"
}
}
}
}
}
ステップ2: 認可コードをアクセストークンと交換する
認可コードを受け取るエンドポイントでは、以下を実行する必要があります。
- 提供されたAlexa認可コードをAlexaアクセストークンと交換します。認可コードとアクセストークンの交換の詳細については、Login with Amazon(LWA)ドキュメントのアクセストークンリクエストを参照してください。
- 前のステップが成功した場合は、アクセストークンを
userId
に関連付けます。 - 次のHTTPコードのいずれかを返します。
- 認可コードをアクセストークンと正常に交換した場合は
HTTP 200(OK)
を返します。 - 認可コードをアクセストークンと交換しようとしたときに問題が発生した場合は
HTTP 400(BAD_REQUEST)
を返します。 - その他の問題が生じた場合は
HTTP 500(INTERNAL_SERVER_ERROR)
を返します。
- 認可コードをアクセストークンと正常に交換した場合は
関連トピック
最終更新日: 2020 年 09 月 28 日