"OpenID Connectは認可のための仕組みであるOAuth 2.0を認証のために拡張したもの" という表現が気になったが実は...

ritouです。

あることがきっかけで、これが気になりました。

10年間で熟成されてしまった感のある「OIDCはOAuth 2.0を"認証もできる(認証用途に利用できる)ように"拡張した」っていう表現だが、プロトコルの解説にあたってもその流れでやられるとモヤるところがあるのでなんとかしておくべきだったのかもしれない。
— 👹秋田の猫🐱 (@ritou) 2024年2月1日

この表現、検索するとたくさん出てくるんです。

仕様策定の時期
OIDC Core 1.0にある "OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol." という記述の解釈

というあたりからこのような表現になっているのでしょう。

ただ、この前提でプロトコル自体を解説、理解しようとすると何かうまくいかないところがあるのではないでしょうか？ と思うところがあります。

特にUserInfo Endpointのあたりについて、

これまでOAuth 2.0でプロフィールAPIを実装したら認証に使えたけど実装がバラバラだった(不便なOAuth認証)
OIDCではそのレスポンスなどを標準化したんだ！

みたいな説明がされていたりします。何を想像して勝手に経緯を補完しているのだと。これは言ってしまえばただのOAuth認証の標準化であり、OIDCの方針とは異なります。

ritou.hatenablog.com

実際、このような流れでは仕様策定が行われていないのです。

OAuthは利用環境や技術スタックの変化に伴い、リソースアクセスのための仕組みとして1.0 -> WRAP(2.0の初期Draft的な立ち位置) -> 2.0と進化してきた
OpenIDも同様の変化を意識しつつ、認証イベントのやり取りのためにOpenID 2.0 -> OpenID Connect と仕様策定が進められてきた
同時期に存在することになったOAuth 1.0とOpenID 2.0を同時に使用するための拡張仕様が策定されたこともあるが、別路線で進んでいた
OpenID Connectでは認証イベントのやり取り(IDTokenのあたり)に加え、UserInfo Endpointから非同期/継続的に最新のユーザー情報を取得するという要件があり、この部分が機能的にOAuthと重なる部分である
OpenID ConnectのJSON、RESTなどを使うという設計方針と、OAuth WRAPあたりが一致していたため、別々に策定を進めるのではなく「OAuth 2.0の上にIdentityレイヤを乗せる形」として最適化を進めるべく合流した

というのが実際に行われたことです。

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol.

上に乗ってる＝後から乗せたって話ではないと言うことです。
— 👹秋田の猫🐱 (@ritou) 2024年2月1日

歴史的に見てもOpenIDが先だし、それから派生してOAuthが出ているので、どっちかというとOpenID Connectを作りながらバリバリ必要な土台（OAuth 2.0, JWx etc.) を作っていったという方が正しい。
— Nat Sakimura/崎村夏彦 (@_nat) 2024年2月1日

この辺りの流れは先日行われたOpenID Summit Tokyo 2024に合わせてNatさんが公開した動画で触れられています。

www.youtube.com