[2] 暗示的承諾は、 JavaScript などのスクリプト言語でブラウザー上で実装されたクライアントのような、 クライアント型が公開であり特定のリダイレクトURL を使うとわかっているクライアントに最適化された、 単純化されたフローです >>1, >>8。
[11] クライアントは、まず資源所有者 (の利用者エージェント)
を認可エンドポイントにリダイレクトします。
この時クライアントは、クライアント識別子 (client_id)、
適用範囲 (scope)、
局所状態 (state)、
リダイレクトURL (redirect_uri) を指定します。 >>8
[12] 認可エンドポイントは資源所有者を認証し、 クライアントのアクセス要求を承認するか拒絶するかを確認します >>8。 承認するなら、アクセストークンを素片識別子に添えてリダイレクトURL へとクライアントをリダイレクトします >>8。
[13] 資源所有者の利用者エージェントはリダイレクトに従いクライアントの資源を要求しますが、 この時 HTTP要求には素片識別子は含まれません。 クライアントは Webページ (通常はスクリプトが埋め込まれた HTML文書) を返します。 Webページのスクリプトは素片識別子からアクセストークンその他の引数を取り出し、 クライアントへと渡します。 >>8
[5] 認可鯖はクライアント認証を行いません >>1, >>8 (クライアントから認可鯖への直接のアクセスが無いので、その機会もありません)。 資源所有者が存在していることと、リダイレクトURL が登録されていることに依拠しています >>8。
[6] アクセストークンはリダイレクトURLに指定されることとなるため、 資源所有者や、資源所有者と同じ装置にある他の応用に晒されるかもしれません >>1, >>8。
[7] 暗示的承諾を使うと認証符号を使う場合のようなアクセストークンを得るまでの往復を節減でき、 効率的ではありますが、便利さのために若干のセキュリティーを犠牲にしています >>1。
[18] 暗示的承諾型を用いている場合、 (悪意のある、または悪意のある者に誘導された) 資源所有者は他のクライアントから取得したアクセストークンを認可鯖からの応答であるかのように見せかけてクライアントに渡すことができてしまいます。 つまり、クライアントを利用する本来の資源所有者と、クライアントがアクセストークンによって資源鯖に対して要求を行う操作上の資源所有者が異なる状態を作れてしまいます。
[20] また暗示的承諾型フローの後に資源鯖から資源所有者のアカウントや電子メールアドレス等を取得して自サービス上のアカウントとする、いわゆるOAuthログインを使うクライアントがあると、他のクライアントにおいて取得したアクセストークンを使ってそのクライアントにも「ログイン」できてしまいます >>22。
[25] Google は「TokenInfo validation」と称して、素片識別子から得たアクセストークンを Google の鯖に送信してその情報を取得し、 適切なクライアントのアクセストークンであるか確認することを求めています >>24。
[23] Final: OpenID Connect Core 1.0 incorporating errata set 1 ( 版) <http://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth>