エンドポイント
[3] 認可鯖は、次のエンドポイントを持つことができます。- 認可エンドポイント >>4
- トークンエンドポイント >>4
- revokeエンドポイント >>5
[7] 認可鯖はクライアントとなるもの (開発者) に対してクライアント登録の
Webページを提供することが期待されています。
[8] 認可鯖は資源所有者に対して、当該資源所有者に関するアクセストークンや更新トークン (が発行されたクライアント) やその適用範囲の一覧を表示したり、
revoke したりする Webページを提供することが期待されています。
[9] 認可鯖 (または認可鯖と協調して動作する他の鯖) は、
これら OAuth の機能とは別に、資源所有者の資格を得たり、
認証してログイン状態を得たりする一連の Webページ群
(= 当該 Webアプリケーションにおけるアカウントの登録やログインのフォームとエンドポイント) を持っているのが普通です。
[10] 認可鯖は、資源所有者に対して認可承諾について電子メールその他の手段で通知するのが好ましいかもしれません。
[12] 例えば重大な操作を行える適用範囲を持つアクセストークンが発行された時、
認可鯖はその旨を資源所有者に報告したいかもしれません。
[11] 例えば資源所有者合言葉credentialsは資源所有者が一旦合言葉をクライアントに渡してしまうと以後何が行われているか資源所有者が一切知ることができないため、
認可鯖は処理を資源所有者に報告したいかもしれません。
[13] 認可鯖は、自身が発行したアクセストークンを通して資源鯖において行われた操作を資源所有者に説明するWebページを提供することがあります。
詳細な利用状況を記録している場合もあれば、最終利用時刻を示す程度の場合もあります。
[14] 認可鯖は、OAuth 以外の方法で OAuth で得られるアクセストークンを資源所有者に提供するかもしれません。
[15] 例えばいくつかのWebアプリケーションは、クライアント開発者でもある資源所有者の便宜を図るため、資源所有者のアカウント管理ページからアクセストークンを発行する機能を提供しています。
[17] OpenID Connect を実装する OAuth 2.0 認可鯖を、
OpenID提供者 (OP)
といいます >>16。すなわち、末端利用者を認証し認証イベントと末端利用者について relying party に claim を提供できる認可鯖をいいます >>18。