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

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

Alexa Skills Kit（ASK）では、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種別のシナリオでは、クライアントはまず認可コードを取得し、取得したコードをアクセストークンと交換する必要があります。また、古いアクセストークンの有効期限が切れたときに新しいアクセストークンをリクエストできるように、更新トークンを取得することもできます。

アカウントリンクは以下のコードとトークンをサポートします。

認可コード

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

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要件を参照してください。

URIの指定方法：

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

AlexaリダイレクトURI

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

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

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

認証画面のURI要件の説明に従って、AlexaリダイレクトURIを登録する必要があります。

アクセストークンURI

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

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

指定方法：

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

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

最終更新日: 2025 年 05 月 27 日