（2018.6.2 この記事を作ったのはまだ英語ページしかないときでしたが、今みたら公式に日本語のリファレンスができていましたので、今後はそちらをご覧ください。m(__)m ）

（2017.4.2書きかけです。）

Linking an Alexa User with a User in Your System
https://developer.amazon.com/public/solutions/alexa/alexa-skills-kit/docs/linking-an-alexa-user-with-a-user-in-your-system

AmazonのAlexaサービスに関する説明の翻訳です。
超意訳なんで、怪しいところが多々あります。
不明点があったら原文をご参照ください。

Overview

いくつかのskillは他システム上のユーザー情報との連携を必要とします。account linkingと呼ばれます。あなたのシステムとAlexaユーザー情報とを紐付けるものだからです。なおSmart Home Skill APIを使うSkill群はAlexaユーザーとdevice cloud accountを紐付けるために、必ずaccount linkingを、（authorization code grant flowとともに）使わなければなりません。

例えば、あなたが「Car-Fu」というタクシー配車サービスを運営していたとします。ユーザーにCar-Fuへの音声アクセスを提供するCustom skillは、「"Alexa、Car-Fu にタクシーをオーダーして"」のように頼めばよく、大変便利です。
このリクエストを完了するには、Car-Fuの特定のユーザーとしてCar-Fuサービスにアクセスするskillが必要です。したがって、Alexaデバイスで使用されるAmazonアカウントとユーザーのCar-Fuアカウントとの間に連携が必要です。

このドキュメントでは、Alexaユーザーとあなたのシステム内のユーザーとの間で連携を確立するための方法を説明します。

ちなみに、アカウントのリンクが必要なのは、スキルが認証を必要とするシステムに接続する必要がある場合のみです。 custom skillが該当セッション内だけで属性を使う場合は、アカウントリンクを使用する必要はありません。その代わりに、リクエスト毎に提供されるuserIdを使うことができます。userIdは、ユーザーがAlexaアプリで自分のスキルを有効にしたときに生成されます。その後ユーザーがskillをdisableするまで、ユーザーからskillへのリクエストの際は同じuserIdが送信されます。

ヒント：Alexa Skills Kit SDK for Node.jsを使用すると、DynamoDBを使用してこのようなデータを保持できます。これを使用するサンプルスキルについては、High Low Gameを参照してください。

How Account Linking Works

OAuth Roles and the Alexa Skills Kit

OAuth 2.0では4つの役割があります。resource owner, resource server, client, および authorization serverです。Alexa Skills KitでOAuthを使う場合の定義は以下となります。

種類	イメージ	説明
Resource owner		エンドユーザー
Resource server		使いたいリソースを保管しているサーバー。アクセストークンを使った通信を受け入れる& レスポンスする必要がある。Car-Fuの例で言えば、Car-Fuサービス本体。保護対象はCar-Fu上のアカウント情報。
Client		ユーザーの代理となって上記Resource serverへアクセスするもの。この例だとAlexa Service。
Authorization server		ID認証してアクセストークンを発行する。この例ならCar-Fuサービスの一部。

Resource serverとAuthorization serverは同じサーバーでも良いです。

How End Users Set Up Account Linking for a Skill

ユーザーは自分たちのアカウントをAmazon Alexa appを使ってリンクすることができます。音声だけでリンクを設立することはできないのでアプリを使うのです。以下のような流れとなります。

スキルをAlexa app内でEnableにする。
認証が走る。あなたのSkillはLinkAccountカードを返し、ユーザーはAlexa appの中でそのカードをつかうことにより先に進む。この方法はcustom skillsでのみ有効であり、smart home skillsでは使えない。

implicit grantを使用するかauthorization code grantを使用するかによって一部のフローは異なりますが、エンドユーザーの手順はどちらでも同じです。

authorization code grantのアカウント連携フロー:
（smart home skillsでもCustom skillsでも同じ）

ユーザーがAlexa Appの中で該当SkillをEnableにします。
Alexa Appの中で、ログインページを表示します。これはデベロッパーポータルでSkillを登録した際にAuthorization URLに書いたページです。 companion app（Alexa appのことか？）がこのURLを呼ぶと、state, client_id, response_type, scope, 及び redirect_uri がクエリ引数として引き渡されます。（下表2参照）
ユーザーは通常使っているログインアカウントを使用してログインします。
あなたのサービス側で、ユーザー認証後にcodeを生成してください。
あなたのサービス側で、redirect_urlにリダイレクトし、その際、URLクエリ引数からstateとcodeを受け取って引き渡してください。
Alexa service側では、返却された情報を検証したのち、あなたのauthorization serverにたいしてaccess tokenとreflesh tokenをリクエストします。その時受け取ったcodeを使います。これら両方ともAlexa userに保存されます。（注；authorization serverとはデベロッパーポータルで*Access Token URI *に書いたものです。）
これにてユーザーのAlexaアカウントはあなたのサービスと連携しました。スキルは使えるようになります。

表2

種類	説明
`state`	Alexa serviceがアカウントリンクされている間つかう。あなたのページはこの値をチェックし、値を返す必要があります。
`Client_id`	あなたがデベロッパーポータルでアカウントリンクを設定した時に発行されたものです。
`response_type`	"code grant flow"の時だけ使う`code`です。
`scope`	要求されたアクセスのレベルを示すアクセススコープの選択肢リストです。あなたはSkillのアカウントリンクを有効にするときにサポートするスコープ群を定義します。
`redirect_url`	あなたのサービス上でユーザー認証完了後、どこにリダイレクトするかを示すURLです。

implicit grantのアカウント連携フロー (custom skillsのみ):
（自分は使わなそーなので省略）

What Happens when a User Invokes a Skill with Account Linking

ユーザーがcustom skillを使えるようになった時、以下のことが起きます。

ユーザーはSkillを呼び出せます。例えば、「Alexa、私にタクシーを注文するようにCar-Fuに依頼してください。」
もし authorization code grantを使っている場合、Alexa serviceはユーザー用に保存されたアクセストークンがまだ有効であることを確認します。もし有効期限切れの場合、Alexa serviceは新しいアクセストークンをあなたのauthrization serverにリクエストするため、リフレッシュトークンを使います。
あなたのSkillあてに送信されたLaunchRequestあるいはIntentRequestには、以前に保存されたユーザーのアクセストークンが含まれます。
あなたのサービス上で、トークンが正しいかの検証を行ってください。
- トークンが有効の場合、あなたのサービス側では必要となるユーザー情報にアクセスし、リクエストに応じて処理を行ってください。その後、喋るべきテキストと、Alexa appに表示するべきcardがあればそれも一緒に返信してください。
- トークンが無効の場合、リンクを促す文章と、LinkAccountカードを返信してください。ユーザーはカード上のlinkをクリックし、連携プロセスを開始することができます。
- LinkAccountカードの例。

smart home skillsでも似たような手順となります。
（使わなそーなので省略）
詳しくはSmart Home Skill API Referenceを参照してください。

What Happens if the User Disables a Skill with Account Linking

ユーザーがAlexa App上でSkillをDisableにした場合、Alexa サービスはアクセストークンを削除します。（リフレッシュトークンもあれば同様に消します。）
これは、ユーザのAlexaアカウントとあなたのサービスのアカウントとの間のリンクを削除することを意味しています。
ユーザーが後でそのスキルを再び有効にする場合、新しいユーザーとしてアカウント連携プロセスを完了する必要があります。

What Do You Need to Add Account Linking to Your Skill?

アカウント連携を実装するには、次のものが必要です。

Authorization Code Grant	Implicit Grant
ユーザーを認証するWebベースのサービス。	（同左）
ログインページを表示してユーザーの資格情報を収集し、ユーザーを認可した後、authorization codeを生成する認証サーバー。	ログインページを表示してユーザーの資格情報を収集し、ユーザーを認可し、そのユーザーを一意に識別するaccess tokenを生成する認証サーバー。
authorization codeとAlexaクライアントのクレデンシャルを受け入れ、ユーザーを一意に識別するアクセストークンを生成する認証サーバー。	不要。

あなたのSkillにアカウント連携をするのは、以下を行う必要があります。

あなたのサービスにアカウント連携のログインページを追加してください。
クラウドにてskill用に作ったweb serviceあるいはLambda functionにアカウント連携ロジックを追加してください。
デベロッパーポータルでアカウント連携を有効にしてください。

それぞれのステップについて詳しく説明します。

Adding Account Linking Support to Your Login Page (Authorization URL)

アカウント連携プロセスでは最初に、Alexa appがあなたのリソースサーバーへのログインページを表示します。目的に適したページを設計・開発してください。このページでは、ユーザーの資格情報を検証してから、アクセストークンまたはauthorization codeを返却する必要があります。

デベロッパーポータルでSkillの設定をする際、このページのURLをAuthorization URLフィールドに入力してください。

Providing the Login Page in the User’s Language

Alexaアプリは、ユーザーのブラウザがサポートされている言語（en-us、en-gb、またはde-de）のいずれかに設定されている場合、ユーザーのブラウザ言語設定を使用して、ローカライズ版のアプリを表示しようとします。他の言語では、デフォルトでen-usに設定されています。

UXに一貫性をもたせるために、ログインページもAlexaアプリと同じ言語で表示する必要があります。言語を取得するには、まずAccept-Languageヘッダーをチェックします。 Alexaアプリは、あなたのサーバーの認証URLを呼び出すときにこれを設定して送りつけます。

ヘッダーが設定されていない場合、ユーザーのブラウザー情報からnavigator.languageまたはnavigator.browserLanguageを参照して言語を検知し、使用することもできます。ナビゲータ言語プロパティを参照してください。

ユーザーの(スマホの)ブラウザ設定は、ユーザーのAlexa対応デバイスで定義されている言語に依存しないことに注意してください。たとえば、ユーザーはechoやecho dotなどのAlexa対応端末ではドイツ語を使用するように設定していも、ブラウザでは英国の英語を使用するように設定できます。この場合、Alexaアプリは英語でレンダリングされ、Accept-Languageヘッダーは英国英語（en-gb）に設定されます。

Parameters Passed to Your Authorization URL

Alexaアプリは、あなたのAuthorization URL:を呼び出すときに、URLクエリ文字列に以下のパラメータを含みます：

　　・stateは、アカウントのリンクプロセスを追跡するためにAlexaサービスによって内部的に使用されます。
　　　　・あなたのページは、リダイレクトURLを呼び出すときに、この値をいじらずに返す必要があります。
　　　　・この値は5分後に失効します。ユーザーがログインしてサービスがユーザーをリダイレクトするのに5分以上かかる場合、stateは無効になり、アカウントのリンク処理は失敗します。この場合、ユーザーはAlexaアプリのリンクをクリックしてやり直す必要があります。
　　・client_idは、あなたが定義した識別子です。これを使用して、アカウント連携で設定したさまざまなスキルを区別するなど、スキル固有の機能をすべて提供できます。デベロッパーポータルでスキルのアカウント連携を有効にするときに、client_idを定義してください。
　　・response_typeの値は、authorization code grantかimplicit grantか、どちらを使用するかによって異なります。
　　　　・authorization code grantの場合はcode
　　　　・implicit grantの場合はtoken
　　・scopeは、Alexaユーザーが必要な権限を示すリストです。デベロッパーポータルでSkillのアカウント連携を有効にするとき、これらのscopeを定義します。
　　　　・この情報は、アクセストークンを生成するときに使用できます。たとえば、リソースサーバーの基本プロファイル情報にアクセスできるトークンを作成できますが、支払い情報へのアクセスは許可されません。
　　　　・複数のスコープを使用できます。リストは、URLエンコードされた半角スペースで区切られます。
　　　　・アカウント連携でどのような権限が付与されるかをユーザーに伝えることもできます。たとえば、ログインページには、「これにより、Car-Fuスキルは、あなたの代わりにタクシーを発注し、料金をアカウントに請求することができます」というようなテキストを表示することができます。
　　・redirect_uriは、ユーザーの認証後にサービスがユーザーをリダイレクトするAmazon固有のリダイレクトURL（OAuth Redirection Endpoint）です。このパラメータに期待できる値は、アカウントリンクの設定時に開発者ポータルにも表示されるため、URLが有効であることを確認できます。

たとえば、ページの承認URLがhttps://www.carfu.com/loginの場合、Alexaアプリから呼び出されるURLは、次のようになります（認証コードの付与(authorization code grant)用）。

https://www.carfu.com/login?state=abc&client_id=alexa-skill&scope=order_car%20basic_profile&response_type=code&redirect_uri=https%3A%2F%2Fpitangui.amazon.com%2Fspa%2Fskill%2Faccount-linking-status.html%3FvendorId%3DAAAAAAAAAAAAAA

Requirements for Your Login Page

ログインページは次の要件を満たしている必要があります。

　　・HTTPS経由で提供される必要があります。
　　・Alexaアプリ内に表示されるため、モバイルフレンドリーでなければなりません。
　　・ページでポップアップウィンドウを開くことはできません。
　　・ユーザーのクレデンシャル(ID/Pssのことか?)を受け入れ、ユーザーを認証する必要があります。
　　・それは次のいずれかでなければならない：
　　　　・リソースサーバー(自分のシステム）上で、ユーザーを一意に識別するアクセストークンを生成する。
　　　　・アクセストークンを取得するために、あなたのauthorizationサーバーに渡すauthorization code認証コードを生成する。（？？）
　　・クエリ引数に渡されるステータスをトラッキングする必要があります。（？？）
　　・ユーザーを認証した後、ページは2つのAmazon提供のリダイレクトURLのいずれかにユーザーをリダイレクトする必要があります。
　　　　・使用するリダイレクトURLは、redirect_uriパラメータとして認可リクエストに含まれます。
　　　　・スキルのアカウント連携オプションをオンにすると、2つのリダイレクトURLがデベロッパーポータルにも表示されるので、ログインページでredirect_uriパラメータに期待される値を確認できます。
　　　　・authorization code grant(=承認コード付与)の場合は、stateとcodeをURLクエリ文字列に含めます。
　　　　・implicit grant(=暗黙の許可)の場合は、URLフラグメントにstate、access_token、およびtoken_typeが含まれます。 token_typeはBearerでなければなりません。

たとえば、Amazon提供のリダイレクトURLが次のようなものであったとします:

https://pitangui.amazon.com/spa/skill/account-linking-status.html?vendorId=AAAAAAAAAAAAAA

認可コード付与(= authorization code grant)の場合、リダイレクトURLは次のようになります。

https://pitangui.amazon.com/spa/skill/account-linking-status.html?vendorId=AAAAAAAAAAAAAA&state=xyz&code=SplxlOBeZQQYbYS6WxSbIA

渡す必要があるパラメータ（stateとcode）は、URLのクエリ文字列部分にあります。

一方、暗黙の許可(=implicit grant)の場合、リダイレクトURLは次のようになります。

https://pitangui.amazon.com/spa/skill/account-linking-status.html?vendorId=AAAAAAAAAAAAAA#state=xyz&access_token=2YotnFZFEjr1zCsicMWpAA&token_type=Bearer

戻さなければならないパラメータ（state、access_token、およびtoken_type）は、URLのURLフラグメント部分にあります。これは、ハッシュタグ（＃）の後の部分です。

About Access and Refresh Tokens

あなたのauthorization server(=認証サーバー)は、システム内のユーザーを一意に識別するアクセストークンを提供する必要があります。

authorization code grant(=認可コード付与)の場合、Alexaサービスはauthorization server（=開発者ポータル上でAccess Token URI として指定されている、あなたのシステムの認証サーバー）を呼び出し、codeとクライアントのクレデンシャルを渡します。そのとき認証サーバーは、アクセストークンとオプションのリフレッシュトークンを返さなければなりません。リフレッシュトークンの返却は任意ですが、アクセストークンが期限切れになった場合、Alexaサービスがこのリフレッシュ・トークンを使用して新しいアクセス・トークンを取得する時のためには、生成して返却しておいたほうが良いです。

implicit grant(=暗黙の許可)の場合、ログインページには、上記のリダイレクトURIの例が示すように、リダイレクトURLを呼び出すときのアクセストークンが含まれています。implicit grantはリフレッシュトークンをサポートしていないため、トークンが期限切れになった場合、エンドユーザーはアカウントを再リンクする必要があります。

どちらのタイプでも、アクセストークンを生成するときは、リソースサーバー固有のトークンを指定します。 GoogleやFacebookなどの他のOAuthプロバイダが提供するアクセストークンは使用しないでください。セキュリティのために、トークンはユーザーを識別する値であり、かつ、推測できてはいけません。

Adding Account Linking Logic to the Service for Your Skill

skillにアカウント連携を追加するには、skillに送信されたリクエストに含まれるアクセストークンを確認して使用するロジックをコーディングする必要があります。

Getting the Access Token from the Request (Custom Skills)

Javaライブラリを使用する場合、onIntent()、onLaunch()およびonSessionEnded()メソッドに渡されるSessionオブジェクトでアクセストークンを使用できます。まずSession.getUser()メソッドを使用してUserを取得し、次にUser.getAccessToken()を呼び出してトークンを取得すれば良いです。

JSONでは、リクエスト内のuserオブジェクトのaccessTokenプロパティでアクセストークンを使用できます。

{
  "version": "string",
  "session": {
    "new": boolean,
    "sessionId": "string",
    "application": {
      "applicationId": "string"
    },
    "attributes": {
      "string": object
    },
    "user": {
      "userId": "string",
      "accessToken": "string"
    }
  },
  "request": object
}

Getting the Access Token from the Request (Smart Home Skills)

アクセストークンは、payloadオブジェクトのaccessTokenプロパティで、device directiveの一部としてスキルアダプタに送信されます。
たとえば、このDiscoverAppliancesRequestdirectiveに注意してください:

{
  "header": {
    "namespace": "Alexa.ConnectedHome.Discovery",
    "name": "DiscoverAppliancesRequest",
    "payloadVersion": "2",
    "messageId": "6d6d6e14-8aee-473e-8c24-0d31ff9c17a2"
  },
  "payload": {
    "accessToken": "string"
  }
}

Validating the Access Token

認証要求に対して、コード上では少なくとも2つのチェックを行う必要があります。

accessTokenが存在することを確認します（カスタムスキルのみ）。ユーザーが正常にアカウント連携していない場合、Javaライブラリ使用時であればUser.getAccessToken()がnullを返します。JSON使用時であればaccessTokenプロパティは存在しません。なおこのチェックはスマートホームスキルには適用されません。
accessTokenが存在していた場合は、それが有効であることを確認し、リソースサーバー内のユーザーを識別します。トークンが存在していてもさまざまな理由で無効だったりするので注意してください。たとえば、

　　・ユーザーがサービス側のアカウントを解約した場合。たとえば、AlexaユーザーがCar-Fuとのアカウントリンクを設定し、その後Car-Fuアカウントを解約した時はこれにあたります。この時点で、Alexaサービスによって格納されたトークンは、存在しないユーザーとなってしまいます。
　　・トークンの有効期限が切れており、新しいトークンも取得できない場合。あなたのサーバーがauthorization code grant方式だがリフレッシュトークンを返却しなかった場合や、そもそもリフレッシュ・トークンをサポートしていないimplicit grantを使用している場合に該当します。

トークンが有効な場合、スキルは要求を正常に処理し、必要に応じてリソースサーバーからデータにアクセスできます。 Car-Fuの例では、スキルはユーザーのプロフィールと支払い情報をCar-Fuサービスから取得し、車を注文し、ユーザーに確認を返します。レスポンスの返却の詳細については、Alexaが送信したリクエストの処理の「レスポンスの返却」を参照してください。

Responding to an Invalid Access Token (Smart Home Skills)

スマートホームスキルのスキルアダプタに送信されたアクセストークンが無効な場合は、DependentServiceUnavailableErrorを返します。その後、Alexaはユーザーに要求を完了できなかったことを伝えます。

Responding to an Invalid or Non-existent Access Token (Custom Skills)

カスタムスキルに送信されたアクセストークンが存在しないか無効である場合、スキルは次の内容を含む応答を返す必要があります。

　　・音声読み上げ用のテキスト。この機能を使用するために、アカウント連携する必要があることをユーザーに説明する内容を記載してください。
　　・リンクアカウントカード。これは、ユーザーに自分のアカウントをリンクさせる特別なタイプのカードです。 Alexaアプリに表示されると、このカードにログインページのURLへのリンクが表示されます。ユーザーはこのカードからアカウント連携プロセスを開始することができます。

リンクアカウントカードを送信するには：

　　・Javaライブラリを使用する場合は、LinkAccountCardクラスのインスタンスを作成し、レスポンスにカードとして含めます。
　　・JSONを使用する場合は、カードタイプをLinkAccountに設定します。

以下はJSONの例）

 {
     "version": "1.0",
     "sessionAttributes": {
       ...(session attributes not shown)
     },
     "response": {
       "outputSpeech": {
         "type": "PlainText",
         "text": "You must have a Car-Fu account to use this skill. Please use the Alexa app to link your Amazon account with your Car-Fu Account."
       },
       "card": {
         "type": "LinkAccount"
       },
       "shouldEndSession": true
     }
 }

ほとんどの場合、ユーザーはアカウントを連携するまでリクエストを続行できないため、この応答はセッションを終了する必要があります。スキルに認証を必要としない意図が含まれている場合は、ユーザーに別の質問をしてセッションを開いたままにしておくとよいでしょう。

When to Require a Valid Access Token

あなたのサービスは、ユーザーがあなたのWebサイトで認証することを要求するすべての要求に対してaccessTokenを検証する必要があります。

スマートホームスキルの場合、これにはすべての指示が含まれます。

カスタムスキルの場合、通常はほとんどのインテントが含まれますが、認証を必要としないインテントを持つことができます。たとえば、Car-Fuカスタムスキルでは、自動車の発注にユーザー認証が必要な場合がありますが、特定の都市でサービスが利用可能かどうかを尋ねる認証は必要ありません。したがって、このスキルのコードでは次のことが行われる可能性があります:

　　・OrderTaxiインテントのハンドラーは、有効なaccessTokenをチェックし、そのトークンを使用してユーザーのCar-Fuプロファイルを取得し、車を注文すること。
　　・一般的なTaxiAvailabilityByCityインテントのハンドラは、accessTokenをチェックする必要はありませんが、Car-Fuサービスで一般情報を検索し、応答を返すこと。

Enabling Account Linking for a Skill in the Developer Portal

アカウントリンクは、Amazon Developer Portalの「設定」ページで有効にします。

通常どおりデベロッパーポータルでSkillを登録したら、** Configuration*ページに移動し、Account Linking or Creation. *でYesを選択します。なおスマートホームスキルではこの選択画面は表示されません。（スマートホームスキルの場合はデフォルトがアカウント連携だから。）

アカウント連携を有効にするには、最低限以下を入力してください。

　　・Authorization URL:ウェブサイトのログインページのURL。ユーザーがアカウントをリンクするときにこのページがどのように使用されるかについては、ログインページにアカウント連携サポートを追加するを参照してください。

　　・Client Id:ログインページがあなたのスキルからのリクエストであることを認識するために使用するID。この値は、Client Idパラメータのauthorization URLに渡されます。authorization code grantを使用する場合、この値はAccess Token URIからアクセストークンを要求する際にAlexaサービスが含むクライアントクレデンシャルの一部です。

　　・Authorization Grant Type:(=認証付与タイプ):アクセストークンを取得するために使用するOAuth 2.0のタイプ。 Alexaスキルキットは2つのタイプをサポートしています：
　　　　・Implicit grant （カスタムスキルで使用可）
　　　　・Authorization code grant（カスタムスキルまたはスマートホームスキルで使用可）
　　・`Authorization code grantの場合、以下の欄も記入する必要があります。

　　　　・Access Token URI:アクセストークンを提供する認証サーバーのURL。
　　　　・Client Secret:AlexaサービスがアクセストークンURIで認証できるように、ユーザーが指定する資格情報。これはclient IDと組み合わせて、Alexaからの要求を識別します。
　　　　・Client Authentication Schemeは、アクセストークンURIからトークンを要求する際にAlexaが使用する[認証のタイプ]https://tools.ietf.org/html/rfc6749#section-2.3.1)を識別します。

　　・Privacy Policy URL:プライバシーポリシーのあるページのURL。このリンクはAlexaアプリに表示されます。アカウント連携を使用するスキルでは必要です。ここで入力したURLは、Privacy＆ComplianceページのPrivacy Policy URL*フィールドにも表示されます。

ログインページが他のドメインのコンテンツを使う場合は、Domain Listにそれらのドメインを入力します。（（ログインページに貼る画像とかだね。）） authorization URLで登録したドメインは書く必要はありません。たとえば、authorization URLがhttps://www.carfu.com/loginであるとします。このページがwww.carfu.com以外のドメインのコンテンツ（画像など）を取得した場合は、それらをDomain Listに追加してください。

リソースサーバーが異なるスコープのアクセスをサポートしている場合は、それらをScopeリストに入力します。 Alexaアプリがあなたのauthorization URLを呼び出すと、ここに入力されたすべてのスコープがscopeパラメータに含まれます。

Redirect URL Values

アカウントのリンクを有効にすると、Redirect URLが表示されます。これは、ログインページが認証後にユーザーをリダイレクトする必要があるURLです。この値は、** Authorization URL**に含まれるredirect_uriパラメータとしてログインページにも渡されます。

複数のRedirect URLが存在することに注意してください。 Alexaアプリは、ユーザーがデバイスを登録した場所に基づいて使用する値を*Authorization URL *に渡します。（（どうやら北米とヨーロッパで２種類みたいです。言語設定と連動しており、間違ったほうを指定した場合は動かないので、両方試してみる必要あり。））

注：スキルを複数の地域に分散させる場合、その地域固有のRedirect URLを使用する必要があります。前述のように、使用するURLは、redirect_uriパラメータのログインページへの呼び出しに含まれています。（？？）

認証後にユーザーをリダイレクトするときにページに含める必要があるパラメーターは、authorization code grant か implicit grantのどちらを使用しているかによって異なります。ログインページの要件を参照してください。

注：アカウント連携を有効にしたskillがエンドユーザーに認定されて公開されると、そのスキルのアカウント連携を無効にすることはできません。

Next Steps

Coding topics (custom skills):
　　・Handling Requests Sent by Alexa
　　・Including a Card in Your Skill’s Response
　　・Implementing the Built-in Intents
Other topics:
　　・Next: Testing a Custom Skill
　　・Return to: Steps to Build a Custom Skill
Reference materials:
　　・JSON Interface Reference for Custom Skills
　　・Custom Skill Java Library Reference
　　・Smart Home Skill API Reference

Alexaと自分のシステムとでユーザー連携する方法