OAuth2.0とOpenID Connectの違い

何番煎じかわかりませんが、あくまで自分が理解するためのアウトプットとして書きます。
勉強中ですので間違っている箇所あれば教えてください。
まずこれらを理解するためには、認証と認可が何なのかを整理しておく必要があります。

認証(Authentication)

認証は簡単に言えば、ユーザーが自分自身を証明することです。
いまログインしているユーザーが誰なのかを特定します。そのシステムにアクセスしようとしている人物が所有者であるかを確認するのが目的です。

日常生活や普段使っているサービスにも認証はたくさんあります。
例えば、パスワードも認証の1つですし、指紋認証や顔認証も1つです。
もう少しシステム的なところへ行くと、SMS認証や2段階認証も認証の1つです。

認可(Authorization)

認可は、認証を受けたユーザーが実際にそのデータやリソースにアクセスする権限があるかを判断します。ユーザーのロールや権限によって必要な許可を与えます。

そのため、基本的には認証⇒認可という流れで行われることになります。

ここまでは一般的な話で分かるかと思いますので、本題に入っていきたいと思います。
自分はここからがあまりよく理解できずしばらく格闘していました。

OAuth2.0

そもそもOAuth(読み方はオーオースです)とはなんなのか、という話ですが、簡単にまとめるとサードパーティのアプリケーション等で、Google等の大手ウェブサービスを利用したりデータを利用したい場合、アクセス権限が必要になります。

ですがもしこのアプリケーションに悪意のあるものが混入していて、ログイン情報(IDやパスワード等)が抜き取られてしまうとどうなるでしょうか。そういったリスクを抑えるため、実際には連携の際にはログイン情報をそのまま使用するのではなく、限られた権限だけ得られるアクセストークンが必要になることがほとんどです。

このアクセストークンをリクエストして、許可を与えられ実際にアクセストークンを受け取る、認可のプロセスを標準化したものがOAuthです。OAuthは認可のみのプロトコルですが、実際には認可サーバーの中でユーザログイン等の処理が挟まれ、認証も行われます。

OAuth単体の記事についてはこれらがわかりやすく見やすいので参考にしてください。
一番分かりやすい OAuth の説明
[多分わかりやすいOAuth]
(https://tech-lab.sios.jp/archives/8026)

事例

自分が実際に業務内で使った事例を少し紹介します。

GitHubにはAPIが公開 (https://docs.github.com/ja/rest) されており、誰でも叩くことが出来ます。公開情報であれば問題ないのですが、プライベートのリポジトリや非公開の情報まで覗かれたり、勝手に編集されてしまったりしたら困ります。そういったものにはアクセストークンが必要になります。

例えば、https://api.github.com/orgs/googleやhttps://api.github.com/orgs/google/membersはパブリックな情報しか返さないため誰でも叩けますが、https/://api.github.com/orgs/google/teamsは権限を持っていないと叩けない(403エラーが返ってくる)ようになっています。

このAPIをサードパーティアプリケーションであるPostmanから叩きたいとなったとき、もちろん手動でアクセストークンを取得してきて入力することも可能なのですが、かなり手間がかかってしまいます。

そこで、OAuthを利用することで、アクセストークンを取得して、リクエストヘッダーに追加する処理までアプリケーション側でやってもらえるようになりました。サードパーティアプリでOAuthを利用することは、イコールリソースやデータへのアクセスを安全にかつ効率的に委譲する仕組みを導入することとなります。

では、次に、OpenID Connectを見ていきます。

OpenID Connect

OAuthは"認可"のプロトコルでしたが、OpenID ConnectはOAuthをベースに拡張された、"認証認可"のプロトコルです。OAuthはアクセス権限を委譲するためのアクセストークンのみを発行していましたが、それに加えてIDトークンを発行します。

IDトークンはJSON Web Token(JWT)と呼ばれる'.'で区切られた３つの部分(ヘッダー、ペイロード、署名) で構成されています。JWTについてはここでは説明は割愛します。
これらをデコードすると、JSONオブジェクトに変換されます。署名に関しては、OpenID Providerの公開鍵を利用し複合化します。ヘッダー、ペイロードを結合しハッシュ化したものと複合化した署名が一致していれば検証成功となります。

アプリケーション側はこれを利用してIDトークンを検証し、OKであれば認証してユーザーとして扱えるようになります。

OpenID Connectのプロトコルを利用する主目的は、
-アプリケーション側に認証処理を持つ必要がなくなる
-ユーザーIDやパスワードなどの認証情報を保管する必要がなくなる

開発目線で考えたときに認証機能を0から作り上げるのはとても多くの手間がかかります。そのため、出来ればどこかにお願いするのが楽です。その時に、OpenID Connectという標準化されたプロトコルを使うことでかなり簡略化して実装することが出来ます。さらに、ワンタイムパスワードや２段階認証など実装を考えるとめんどくさい機能も使うことが出来ます。
ユーザー目線で見たときにも、複数サービスでIDやパスワードの管理が必要なくなるのは大きな利点になります。

OpenID Connectとは一言で言ってしまえば、面倒なID・パスワードの管理や認証処理を他にお任せするためのプロトコルといえます。

まとめ

OAuthとOpenID Connectの違いを表にしてまとめてみるとこのような形になります。

項目	OAuth2.0	OpenID Connect（OIDC）
目的	認可（リソースへのアクセス権限）	認証（ユーザーが誰であるかの確認）
トークン	アクセストークン	IDトークン + アクセストークン
ユーザー情報	リソースサーバーから取得	IDトークンまたはUserInfoエンドポイントから取得
プロトコル	認可フレームワーク	OAuthを拡張した認証プロトコル
使用例	リソースへのアクセス権限を付与	ユーザー認証とシングルサインオン（SSO)
セキュリティ	アクセストークンの保護	IDトークンの署名検証と暗号化
標準化	RFC 6749	OIDC Core 1.0

この記事を書くことである程度自分の中では整理できたと思います。
実際サービスと連携したい場合に、GitHubのようにOpenID Connectを使用せず、OAuthでも独自拡張をしているものがある場合があり、よく理解しておかないとこんがらがる可能性があるのでよく覚えておきましょう。