認可サーバーが返す認可レスポンスと、それに伴うリダイレクト処理について説明します。全フローの図解と動画)。Endpoint)に認可リクエストを投げるところから処理が始まります。渡す、ということです。ブラウザは、認可サーバーとのやりとりを開始します。認可画面には、認可リクエストに関する情報(クライアントアプリケーションに関する情報や要求されている権限の一覧など)が表示されます。ユーザーは、その内容を確認し、当該認可リクエストを承認するか拒否するかを決定します。ブラウザは認可サーバーにその旨を伝えます。リクエストを投げます。レスポンス)を返します。この応答のことを認可レスポンスと言います。そのため、認可レスポンスに含まれているレスポンスパラメーター群をクライアントアプリケーションに渡すためには、何らかの工夫が必要です。その工夫とは、リダイレクトを使うことです。ステータスコードを用います。ないケースについては後述)。認可レスポンスの内容は次のようになります。ヘッダーが示す場所に遷移しようとします。Authlete(オースリート)社のウェブサイトの内容が表示されることになります。ブラウザを別の場所に遷移させる(リダイレクトする)ことができます。値は、「遷移先」と「認可レスポンスパラメーター群」で構成されています。いうクエリーパラメーターを添えてアクセスしにいきます。いう認可リクエストパラメーター群を受け取ることになります。クライアントアプリケーションそのものの一部であれば、クライアントアプリケーションは認可レスポンスパラメーター群を受け取ることができます。遷移先がクライアントアプリケーションの一部ではなかったとしても、クライアントアプリケーションの開発者と遷移先プログラムの開発者が同一人物であれば、遷移先プログラムが受け取った認可レスポンスパラメーター群を何らかの方法でクライアントアプリケーションに渡すこと、もしくは、間接的にクライアントアプリケーションに利用させることが可能でしょう。いずれにしても、遷移先がクライアントアプリケーション開発者の管理下にあれば、クライアントアプリケーションは認可レスポンスパラメーター群を受け取ることができます。遷移先を事前に登録しておくそういうわけで、クライアントアプリケーション開発者は、認可レスポンスパラメーター群を受け取る場所となる遷移先を、事前に認可サーバーに登録しておきます。事前登録しておけば、認可レスポンスは次のようになるでしょう。公開しているウェブサービスは、大抵の場合、クライアントアプリケーション開発者がクライアントアプリケーション群を管理するためのウェブコンソールを提供しています。登録する場所がどこかに必ずあるはずです。用いるべきか決められないので、認可サーバーは認可レスポンスを生成する際に困ってしまいます。用いて欲しいかを指定します。リクエストパラメーターは必ず指定しなければなりません。認可コードフローでは、認可レスポンスを受け取ったあと、クライアントアプリケーションは続けて、認可サーバーのトークンエンドポイントにトークンリクエストを投げます。リクエストパラメーターを指定する必要があるので、注意してください。認可コードフローでは、認可レスポンスパラメーター群は、クエリー部に埋め込まれる約束になっています。場合、それは認可コードフローですので、認可レスポンスパラメーター群はクエリー部に埋め込まれます。後に続くことに注目してください。https://client.com/callback?code=123&state=abc一方、インプリシットフローでは、認可レスポンスパラメーター群は、フラグメント部に埋め込まれる約束になっています。場合、それはインプリシットフローですので、認可レスポンスパラメーター群はフラグメント部に埋め込まれます。後に続くことに注目してください。リクエストに含めない」、という動作をします。含まれていないことに注目してください。待ち受けるプログラムは、フラグメント部の情報を知ることはできません。ブラウザの動作を意識したものです。リクエストにフラグメント部が含まれないとすると、遷移先で待ち受けるプログラムは認可レスポンスパラメーター群を取得することはできません。これはどういうことでしょうか?実は、インプリシットフローにおいては、遷移先で動くプログラムは、認可レスポンスパラメーター群を取得しようとはしません。そのものがクライアントアプリケーションです。ブラウザ内で動作します。情報にアクセスすることができます。アプリケーションであれば、フラグメント部に埋め込まれた認可レスポンスパラメーター群を取得できます。コードで取得できます。フラグメント部を取得する。アプリケーションにアクセストークンを直接発行したいときに使う」ということが言えます。サーバーのログに(アクセストークンを含む)フラグメント部の情報が記録されることはない、という利点が得られます。これにより、アクセストークン漏洩のリスクを下げることができます。サーバーにアクセスしにいくことになります。サーバーを用意しておかなければならないということです。サーバーを用意することが適切かもしれません。サーバーを用意するのは手間がかかります。して用い、そのカスタムスキームにクライアントアプリケーション自身が反応するように事前に設定しておきます。サーバーを介さずともクライアントアプリケーションが認可レスポンスパラメーター群を取得することができるようになります。登録しておくと、認可レスポンスは次のようになります。いう見慣れないものであるため、自分自身では処理できません。処理できる外部プログラムがシステム内に存在するかどうかを調べます。存在すれば、その外部プログラムに処理を委譲します。ヘッダーの値を渡すことになります。このような手順を踏むことで、めでたくクライアントアプリケーションに認可レスポンスパラメーター群が渡ってきます。カスタムスキームに反応する外部アプリケーションを登録する方法はシステム毎に異なります。次のような設定を追加することでカスタムスキームに反応できるようになります。/>カスタムスキームに反応する外部アプリケーションの登録方法については、各システムの技術文書を参照してください。いう要求事項があります。なければならないということです。裏を返すと、カスタムスキームは使えません。Redirection」で言及されている手法を使うことになります。特別に扱うことができます。引数として外部アプリケーションを起動します。この動作により、クライアントアプリケーションは、カスタムスキームを用いたときと同様に、リダイレクトエンドポイントの処理を自ら実装することができます。使えるわけではないので注意してください。同じカスタムスキームに反応する外部アプリケーションが複数登録されている場合、認可リクエストを発行したクライアントアプリケーション以外のアプリケーションが認可レスポンスを受け取ってしまう可能性がでてきてしまいます。attack)が発生しました。悪意のあるアプリケーションは、横取りした認可コードを用いて認可サーバーのトークンエンドポイントにアクセスし、アクセストークンを取得することができてしまいました。PKCE(ピクシー)と呼ばれる仕様です。リクエストパラメーターをつけることが必須となります(仕様上必須ではないですがセキュリティー的観点から必須です)。サポートしておかなければなりません。サーバーとクライアントが実装すべきこと』という記事を参照してください。認可レスポンスパラメーター群は、認可コードフローであればクエリー部に、インプリシットフローであればフラグメント部に置かれます。指定するとフラグメント部に置かれるようになります。指定してはいけないことになっています。指定することぐらいです。続く部分)に埋め込まれています。受け付けないのであれば、たいして有用ではありません。意義ある変化をもたらします。含まれるようになります。次の認可レスポンスの例は、当該仕様書から抜粋したものです。