アカウントリンクのしくみ



Alexaスキルでは、アカウントリンクにOAuth 2.0が使用されます。このトピックでは、OAuth 2.0の用語を紹介し、スキルがこのフレームワークにどのように対応しているかを説明します。

OAuthロールとAlexaスキル

OAuth 2.0では次の4つのロールを定義しています。リソースオーナー、リソースサーバー、クライアント、認可サーバーです。以下の表は、これらのロールの定義とAlexa Skills Kitのコンテキストでのロールの仕組みを表しています。

ロール OAuthの定義 カスタムスキルのロール

リソースオーナー

リソースサーバーの保護されたリソースにアクセスする権限を付与することができる個人のことです。

スキルをシステムのユーザーアカウントに接続して、そのシステムの保護されたリソースにアクセスしたいAlexaユーザーです。

ユーザーが配車を依頼できるカスタムスキル(「タクシー予約」)の場合であれば、タクシー予約スキルを有効にしてそのアカウントにリンクして配車をリクエストしたいと考えているユーザーのことです。

リソースサーバー

ユーザーがアクセスしたいリソースをホスティングするサーバーです。

タクシー予約の例では、リソースサーバーはタクシー予約ユーザーのプロフィールを含むデータベースのことです。ユーザーのタクシー予約アカウントのプロフィールと支払い情報は保護されたリソースであり、このデータベースに格納されています。

クライアント

リソースオーナーの認可により、リソースオーナーに代わってリソースサーバーにリクエストを行うアプリケーションのことです。

スキルがこれに当たります。スキルはアクセストークンを使ってリソースサーバーの情報をリクエストします。

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

タクシー予約の例では、このスキルはリソースサーバーと通信してユーザーのタクシー予約アカウントのプロフィールと支払い情報を取得することで、ユーザーに代わって車を手配できるようになります。

認可サーバー

リソースオーナーのIDを認証してアクセストークンを発行するサーバーです。リソースサーバーと同じでも、別であってもかまいません。

タクシー予約の例では、認可サーバーはユーザーを認証してユーザーを有効なタクシー予約ユーザーとして識別するアクセストークンを発行します。取得したトークンは、ユーザーのタクシー予約アカウント情報をリソースサーバーから取得するのに使われます。

ロール OAuthの定義 スマートホームスキルのロール

リソースオーナー

リソースサーバーの保護されたリソースにアクセスする権限を付与することができる個人のことです。

スマートホームスキルをデバイス制御クラウドのユーザーアカウントに接続したいAlexaユーザーです。

照明を制御できるスキル(「マイライト」)の場合であれば、スキルを有効にしてマイライトアカウントをリンクし、Alexaでマイライトデバイスを制御できるようにしたいユーザーのことです。

リソースサーバー

ユーザーがアクセスしたいリソースをホスティングするサーバーです。

マイライトの例では、ユーザーの家で照明のスイッチを制御できるクラウドベースのマイライトサービスがこれに当たります。ユーザーのマイライトアカウントと、サービスが制御するユーザーのスマートデバイスに関する情報が、保護されたリソースです。

クライアント

リソースオーナーの認可により、リソースオーナーに代わってリソースサーバーにリクエストを行うアプリケーションのことです。

スキルがこれに当たります。スキルはアクセストークンを使ってリソースサーバーの情報をリクエストします。

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

マイライトの例では、マイライトスキルがリソースサーバーと通信してユーザーの照明に関する情報を取得します。スキルは取得した情報を使用して照明をオンまたはオフにします。

認可サーバー

リソースオーナーのIDを認証してアクセストークンを発行するサーバーです。リソースサーバーと同じでも、別であってもかまいません。

マイライトの例では、このサーバーはユーザーを認証してユーザーを有効なマイライトユーザーとして識別するアクセストークンを発行します。

リソースサーバーと認可サーバーの所有者

リソースサーバー認可サーバーの所有者が同じ人や企業である必要はありません。以下に、よくあるシナリオの一部を紹介します。

シナリオ 意味

リソースサーバーと認可サーバーの両方を所有しています。

サービスの認可サーバーを自身で構築しました。

タクシー予約サービスを開発しました。このサービスの一環として、タクシー予約プロフィールを保存するリソースサーバーと、タクシー予約システムのユーザープロフィールへのアクセスを付与するトークンを発行する認可サーバーの両方を構築しました。

リソースサーバーは所有していますが、認可サーバーは所有していません。

Login with Amazonなどサードパーティの認可サーバーを使用しています。認可サーバーはリソースサーバーのユーザーにマッピングできるデータを提供します。

タクシー予約サービスを所有していますが、認可サーバーは構築していません。リソースサーバーにはユーザーのプロフィールデータが含まれています。Login with Amazonを使用してユーザーの認証を行い、Amazonのprofile:user_idを使ってタクシー予約データベースのユーザープロフィールにアクセスします。

リソースサーバーも認可サーバーも所有していません。

ユーザー認証を必要とするサードパーティのAPIに接続しています。

タクシー予約を所有していませんが、タクシー予約はOAuth 2.0をサポートする公開APIを提供します。公開APIへの接続、ユーザーの認証、車を手配するAPI呼び出しを行う非公式のタクシー予約スキルを開発しています。

Grant種別とスキルモデル

OAuth 2.0で、grantとは、リソースへのアクセスを許可するアクセストークンをアプリケーションが取得する方法を指します。スキルでアカウントリンクに使用できるauthorization grantの種別は、スキルモデルによって異なります。詳細は、以下の表を参照してください。

スキルモデル ユーザーの認可

カスタムモデル

ユーザーの認可とアクセストークンの取得に、Authorization code grantまたはImplicit grantのどちらかを使うことができます。

スマートホームモデル
ビデオモデル
会議モデル

ユーザーの認可とアクセストークンの取得には、Authorization code grantを使う必要があります。

音楽モデル

ユーザーの認可とアクセストークンの取得には、Authorization code grantを使う必要があります。

ベビーアクティビティ

相互認証と相互アクセストークンを使用する必要があります。

アカウントリンクに必要な情報

コンポーネントのいずれかを所有しない、または開発していないシナリオについては、サードパーティサービスのドキュメントを参照して以下の点を判断してください。

  • 認可サーバーがOAuth 2.0をサポートするかどうか。
  • 認可サーバーでサポートされるAuthorization grant種別
    • カスタムスキルの場合、Authorization code grantまたはImplicit grantを使用できます。認可サーバーでサポートされている場合はAuthorization code grantを使うことをお勧めします。
    • スマートホームスキル、ビデオスキル、音楽スキル、会議スキルの場合、Authorization code grantをサポートする認可サーバーを使う必要があります。
  • セキュリティプロバイダーにアプリケーションを登録する方法
  • アカウントリンクを設定するときに必要なURI

    具体的なコンフィギュレーションの詳細については、Authorization code grantを設定するImplicit grantを設定するを参照してください。

  • 認証されたユーザーに代わってデータにアクセスするためのAPI呼び出し

OAuthのリソース:

その他のリソース: