OpenID Provider

認可鯖 (OAuth)

[2] 認可鯖 (authorization server) は、 資源所有者認証に成功し認可を得た後にクライアントアクセストークンを発行するです >>1

仕様書

エンドポイント

[3] 認可鯖は、次のエンドポイントを持つことができます。

[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提供者 (OpenID Provider) (OP) といいます >>16。すなわち、末端利用者認証認証イベントと末端利用者について relying partyclaim を提供できる認可鯖をいいます >>18

歴史

[6] OAuth 1.0 では認可鯖資源鯖に相当するものがまとめて (サービス提供者) と呼ばれていました。