OAuth 2.0 と OpenID Connect とは
OAuth 2.0 と OpenID Connect について雰囲気で分かってたつもりだったので、調べて備忘録と言語化のために記事を書きます。
認証と認可
前提知識として『認証』と『認可』についてです。
認証 は、クライアントが誰（Who）であるかを特定すること。
英語でいうと Authentication。AuthN と表現されることもあります。認可 は、クライアントがリソースに対して何（What）ができるのかを特定すること。
英語でいうと Authorization。AuthZ や AuthR と表現されることもあります。
OAuth 2.0
OAuth 2.0 は『認可』の仕組みです。
OAuth 2.0 は、アクセストークンの要求とその応答を標準化したものです。
アクセストークン
クライアントが、リソースオーナーのデータを利用することを許可されていることを示すもの。
（データの利用許可書のようなものかな）
OAuth 2.0 の登場人物（ロール）
- リソースオーナー(resource owner)
- データの本来の持ち主
- リソースサーバー (resource server)
- リソースオーナーのデータを預かってる
- クライアント (client)
- Web アプリケーションやクライアントアプリケーションなど、リソースサーバーが持っているデータの要求する者
- 認可サーバー (authorization server)
- アクセストークンの発行者
OAuth 2.0 のプロトコルフローの概要
認可サーバーは、クライアントからの認可要求をリソースオーナーにリダイレクトした後、その許可要求の許諾を受けて、アクセストークンを生成して、クライアントにアクセストークンを渡す。
OpenID Connect
OAuth 2.0 をベースにした『認証』の 仕組みです。
OpenID Connect は、ID トークンの要求とその応答を標準化したものです。
ID トークン
どの OpenID プロバイダーから、
どのユーザーの情報を、
どのアプリケーション（利用者）に対して、
いつまでの有効期限で、
いつ発行されたのか、
という情報を必ず含んだもの。
ID トークンは、ユーザーが認証されたことの証なので、それを利用することで ID 連携が実現できます。
OAuth 2.0 と OpenID Connect の関係性
OpenID Connect が OAuth 2.0 をベースとしているため、プロトコルフローが似ています。
そのため、OpenID Connect で登場した OpenID プロバイダー が OAuth 2.0 の 認可サーバー を兼任することが多くなりました。
（アクセストークン発行と ID トークン発行を同時にやっちゃいましょうという流れですね。）
OpenID Connect のウェブサイトでは、次のように述べられてます。
(Identity, Authentication) + OAuth 2.0 = OpenID Connect
https://openid.net/connect/faq/
