アカウントリンクの構成要素

アカウントリンクの構成要素

Alexa Skills Kitでは、AlexaユーザーのAmazonアカウントとサービスの既存アカウントのリンク作成に、OAuth 2.0認証フレームワークを使用します。OAuth 2.0は、ユーザーが以前に設定したアカウントから、ユーザーの権限を使ってAlexaが情報にアクセスできるようにする方法を定義します。

このトピックでは、最も一般的なAlexaスキルへのアカウントリンクの実装である authorization code grant種別を使ったAlexaアプリのみのアカウントリンクにおける、OAuth 2.0の概念について説明します。ほかのGrant種別（implicit grantなど）や別のフロー（アプリ間のアカウントリンク）といったそれほど一般的ではないアカウントリンクの方法についてはここでは説明しませんが、共通の概念が多数あります。

概要

Alexaスキルにおいて、アカウントリンクは、「Alexaスキルがシステムのユーザーアカウントにアクセスするには、アクセストークンを使う必要がある」という概念に基づいています。つまり、「アカウントをリンクする」とは「アクセストークンを取得するユーザーの権限を取得する」ことであり、API呼び出しで取得したアクセストークンを使うことで、ユーザーデータを含むサーバーにアクセスできます。ここでは、自社でユーザーデータを含むサーバーを持っていることを前提で説明します。ただし、サードパーティでサーバーを持つことも可能です。

最も一般的なシナリオ（authorization code grant種別）では、Alexaサービスはアクセストークンを直接取得しません。まず、認可コードを取得し、コードをアクセストークンと交換します（任意で、古いアクセストークンの有効期限が切れた場合に新しいアクセストークンをリクエストするために、更新トークンと交換することもできます）。以下の図は、このトピックで後述するアカウントリンクの主要コンポーネントの関係を示しています。アカウントリンクフローのユーザーエクスペリエンス例については、Alexaスキルにおけるアカウントリンクのユーザーエクスペリエンスを参照してください。

Alexaアプリ間アカウントリンク

概念

このセクションでは、アカウントリンクを実装する際に必要となる概念について説明します。

OAuthのロール

OAuth 2.0では、リソースオーナー、リソースサーバー、クライアント、認可サーバーという4つのロールを定義しています。以下のセクションでは、Alexaスキルにおけるこれらのロールについて説明します。例では、ユーザーが配車を依頼するカスタムスキル（「タクシー予約」）と照明を制御するスマートホームスキル（「マイライト」）という架空のスキルを使います。

リソースオーナー

スキルを有効にしてシステムアカウントにリンクするAlexaユーザーです。

リソースサーバー

Alexaスキルがユーザーの権限でアクセスするのに必要な、保護されたリソース（ユーザーデータ）をホストするサーバーです。

クライアント

Alexaユーザーに代わってユーザーの権限を使い、リソースサーバーにリクエストを行うAlexaスキルです。

スキルがOAuthクライアントであっても、Alexaはスキルに代わって一部の操作を行います。たとえば、Alexaは認可サーバーに対してアクセストークンを取得するリクエストを行います。その場合でも、リソースサーバーにある保護されたリソース（ユーザーデータ）にアクセスする唯一のコンポーネントなので、スキルがクライアントだとみなされます。

認可サーバー

AlexaユーザーのIDを識別し、システムのユーザーに対して認証するサーバーです。認可サーバーは、次の点でアカウントリンクにおける重要な役割を果たします。 1）ユーザーにシステムへのログインページを表示します。2）システムのユーザーを認証します。3）ユーザーを識別する認可コードを生成します。4）Alexaアプリに認可コードを渡します。最後に、5）Alexaサービスからの認可コードを受け入れ、Alexaサービスにシステム内のユーザーデータへのアクセスに使用するアクセストークンを返します。認可サーバーがトークンサーバーとも呼ばれるのは、この最後のステップに由来しています。

Login with Amazonなどのサードパーティ認可サーバーや独自の認可サーバーを使用できます。どちらの場合も、OAuth 2.0をサポートしている必要があります。サードパーティの認可サーバーを使う場合、認可サーバーはリソースサーバーのユーザーにマッピングできるデータを提供します。たとえば、Login with Amazonを使用してユーザーの認証を行う場合、Amazonのprofile:user_idを使ってデータベースのユーザープロファイルにアクセスします。

認証画面のURI要件については、認証画面のURI要件を参照してください。

コードとトークン

前述のとおり、Alexaスキルにおけるアカウントリンクではリソース（この場合はサービスのユーザーアカウント）へのアクセスにアクセストークンを使用します。最も一般的なシナリオ（authorization code grant種別）では、クライアントはまず、認可コードを取得し、コードをアクセストークンと交換します。任意で、古いアクセストークンの有効期限が切れた場合に新しいアクセストークンをリクエストするために、更新トークンと交換することもできます。これらについては、以下で説明します。

認可コード

認可サーバーがAlexaサービスに渡すコードです。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つがあります。Alexaのアカウントリンクに関するドキュメントでは、セキュリティや使いやすさの点で推奨されるAuthorization code grant種別を重点的に説明します。

Authorization code grant種別

Alexaサービスが認可サーバーから認可コードを取得し、コードをアクセストークンと交換して、スキルへのリクエストでアクセストークンを渡すというGrant種別です。（これについては、コードとトークンのセクションでも説明してあります。） Authorization code grantでは、認可サーバーは、ユーザーが認可サーバーにログインした後、Alexaアプリにリダイレクトされて戻る際、認可コードをクエリ文字列に含めることによってAlexaサービスに渡します。Alexaサービスはこのコードを使って、アクセストークンエンドポイント（URI）でアクセストークンと更新トークンのペアをトークンサーバーにリクエストします。古いトークンの期限が切れたら更新トークンを使って新しいアクセストークンをリクエストできます。どうしてもImplicit grant種別を使う必要ある場合を除き、Authorization code grant種別を実装してください。

Implicit grant種別

ほかのシステムの情報にアクセスするためにエンドユーザーの認可をリクエストするGrant種別です。Implicit grantでは、ユーザーがログインすると認可サーバーがアクセストークンを返します。Authorization code grant種別と比較して、このGrant種別は安全性が低く、使用できるケースも限定されています。Implicit grant種別を使用できるのはカスタムスキルのみです。

相互認可

ユーザーがリソースペアを同期し、更新できる場合のことを相互認可と言います。通常のアカウントリンクでは、Alexaがシステムのリソースにアクセスできます。相互認可では、さらに一歩進んで、ユーザーもAlexaリソースにアクセスできます。

ほとんどのOAuthサーバーでは、システムのユーザーを認証・認可する機能のみを提供しています。ただし、一部のスキルでは、Alexaバックエンドとプロアクティブに通信して更新を行う必要があります。Alexaでは、相互認可エンドポイントによりこの機能を実現します。つまり、相互認可エンドポイントをホストして、Alexaから認可コードを取得します。

アカウントリンクで使用するURI

このセクションでは、アカウントリンク関連のURIについて説明します。

名前 説明 指定と取得の方法

認証画面のURI

認可サーバーのURIです。Alexaサービスに認可コードを提供します。Alexaサービスはこれらのクエリパラメーターを使って認証画面のURIを呼び出します。

認可サーバー関連要件のリストについては、認証画面のURI要件を参照してください。

指定方法：

  • 開発者コンソール（認証画面のURI）
  • ASK CLI（Authorization URL）
  • SMAPI（authorizationUrl）

AlexaリダイレクトURI

ユーザーがシステムにログインすると、認可サーバーはこのURIを呼び出してユーザーをAlexaアプリにリダイレクトします。

Alexaサービスが認証画面のURIを呼び出す際、Alexaサービスがredirect_uriクエリパラメーターとして渡した値を使用します。

AlexaリダイレクトURIは、開発者コンソール（Alexaのリダイレクト先のURL）、ASK CLI、SMAPI（redirectUrls）でも確認できます。ただし、これらのソースでは複数のリダイレクトURIが表示されます。最終的な値はユーザーがどのAlexaデバイスから登録したかによって異なるためです。前述のとおり、Alexaがクエリパラメーターとして認証画面のURIに渡すredirect_uriを使います。

認証画面のURI要件に記載したように、AlexaリダイレクトURIを登録する必要があります。

アクセストークンURI

トークンサーバーのURIです。認可コードを受け取って、Alexaサービスがシステムのユーザーデータにアクセスするのに使用するアクセストークンと更新トークンのペアを返す認可サーバーのエンドポイントになります。Alexaサービスは、アクセストークンURIにPOSTリクエストを行い、パラメーターに認可コードを含めます。トークンサーバーは応答し、JSONにアクセストークンと更新トークンを含めます。

アクセストークン関連の要件リストについては、アクセストークンURIの要件を参照してください。

指定方法：

  • 開発者コンソール（アクセストークンURI）
  • ASK CLI（Access Token URI）
  • SMAPI（accessTokenUrl）

このページは役に立ちましたか？

最終更新日: 2022 年 06 月 30 日