OAuth=認可、OpenID Connect=認証ではないという記事を作成するために
マロン今スクラップではOAuth=認可、OpenID Connect=認証とすることは適切ではないことを投稿するための情報集めとする。
マロンRFC6479からOAuthの目的を確認する
OAuthは, 認可レイヤーをもうけてクライアントとリソースオーナーの役割を分けることで, これらの問題の解決に取り組む. OAuthでは, クライアントは, リソースオーナーのコントロール下にありリソースサーバーによってホストされているリソースへのアクセス権を要求する. そしてリソースオーナーのクレデンシャルそのものとは別のクレデンシャルを取得する.
マロンOAuthは認可プロトコルだから、認証しないは誤り
RFC6479「はじめに」の例で以下の記載がある
そのかわり, 彼女は写真共有サービスの信任を得たサービス (認可サーバー) に対して認証を行い, 印刷サービスへのアクセス権限委譲用クレデンシャル (アクセストークン) を発行させる.
認証自体はOAuthでもいる。ただ、その認証が我々が想像するリソースオーナーのユーザー名とパスワードではないだけ。
認証するのは「クライアント」の認証、リソースオーナーの「認証」ではない
マロンOpenID Connectを認証、OAuthを認可と分類してしまうのは以下の記載ではないかと考える
OpenID Connect は OAuth 2.0 認可プロセスを拡張し, 認証目的で利用できるようにする.
この文の認証という言葉を誤解する人がいることによって、OAuth=認可、OpenID Connect=認証の図式ができるのかも。
OAuthも認証自体はしているから、誰の認証かを考えないといけない。
マロンOpenId Connectの目的は以下のとおりである。
このプロトコルは Client が Authorization Server の認証結果に基づいて End-User のアイデンティティを検証可能にする.
ここでいうEnd-UserはOAuth側のRFCに記載がある。
リソースオーナー (resource owner)
保護されたリソースへのアクセスを許可するエンティティー. リソースオーナーが人間の場合, エンドユーザーと呼ばれる.
これらのことからOpenID Connectは人間であるリソースオーナーが誰かを識別できるようにすることが目的だと考えられる？