認可グラントを選択する
ウェブサイトでは、アクセストークンの取得にインプリシットグラントと認可コードグラントという2つのメカニズムを使用できます。どちらの認可グラントも、ログイン時にユーザーエージェント（ユーザーのブラウザ）をAmazon.comにリダイレクトします。
ログイン後、ウェブサイトがインプリシットグラントをリクエストすると、URIにフラグメントとしてアクセストークンが埋め込まれ、ユーザーエージェントはクライアントウェブサイトに戻されます。その後、ウェブサイトはスクリプトを使用してユーザーエージェントからデータを取得します。ウェブサイトが認可コードをリクエストすると、ユーザーエージェントはウェブサイトに戻され、そのURIにクエリ文字列として認可コードが渡されます。ウェブサイトは、バックグラウンドでAmazonに対して安全なHTTPの呼び出しを行い、認可コードをアクセストークンと交換します。
Login with Amazonアプリを実装するには、使用する認可グラントを選択する必要があります。
アプリに適したグラントタイプの判断方法
どちらのグラントにも一長一短があります。認可コードグラントの長所は、インプリシットグラントよりもセキュリティを確保しやすいことです。アクセストークンのリクエストはクライアントウェブサイトと認可サービスとの間で直接行われるため、ユーザーはそのプロセスに関与しません。また、認可コードグラントではリフレッシュトークンも使用されるため、クライアントウェブサイトはほぼ永続的にユーザーのプロファイルデータにアクセスできます。
認可コードグラントの短所は、実装が難しく、サーバー側のスクリプトを使用しなければならないことです。また、認可コードグラントの方が、インプリシットグラントよりもラウンドトリップが多くなります。
インプリシットグラントの長所は、アクセストークンの受け取りと保存をウェブブラウザに依存していて、実装が比較的簡単であることです。クライアントアーキテクチャがサーバー側のスクリプトに対応していない場合、Login with Amazon認可サービスで使用できるのはインプリシットグラントのみです。また、インプリシットグラントの方が、認可コードグラントよりもラウンドトリップが少なくなります。
インプリシットグラントの短所は、ユーザーのブラウザがアクセストークンをリクエストするため、アクセストークンの値をユーザーに知られることです。厳格なセキュリティの観点からいうと、この情報は機密として扱うことをお勧めします。また、インプリシットグラントでは、アクセストークンの有効期限が切れると、リソースに引き続きアクセスするためにユーザーの再認証が必要となります。認可コードグラントでは、リフレッシュトークンを使用して、ユーザーを介さずに新しいアクセストークンを取得できます。
サーバー側のスクリプトを使用できない場合は、選択できるのはインプリシットグラントのみです。サーバー側のスクリプトを使用できる場合は、認可コードグラントをお勧めします。