ritou です。
一日遅れましたが、アドカレ最終日の記事です。
一個誰かが忘れてる以外は埋まってますね！特に中盤までのAuthlete無双ありがとうございます。
前日(24日)の記事も大作でございました。
今回は巷でよく言われている「OAuthは認可、OIDCは認証」ってフレーズについて整理しましょう。
「OAuthは認可」わかる
OAuthは(最近だと3rdパーティーに関わらず)あるアプリケーションに対して安全なリソースアクセスの提供を実現するための仕様です。 リソースオーナーはそのアプリケーション自身かもしれないし、アプリケーションのユーザーかもしれません。 リソースアクセスを提供する側が認可し、利用する側は認可されてリソースアクセスをします。これは特に問題ないでしょう。
「OIDCは認証」わかる？
OIDCは認証、これはどういう意味かわかりますか？ もしかしたら「ユーザー情報を受け取ったサービスがそれを "認証" に利用するから」みたいな印象かもしれません。 いわゆるソーシャルログインってそういうものですね。それを実現するための仕様がOIDCですよと。
果たしてこれは正しいのでしょうか？
仕様の最初の方を読んでみましょう。
It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner. これにより、クライアントは認証サーバーによる認証に基づいてエンドユーザーの身元を確認できるほか、相互運用可能かつREST的な方法でエンドユーザーに関する基本プロファイル情報を取得できます。
認証する、してるのは誰かというと、認可サーバーです。その結果を提供(なので認可サーバー側はIdentity Providerと呼ばれる)することでRPは身元を確認できるとありますね。RPはそれを利用して "認証する" なんて実は書いてないのです。
そのあとは仕様の関係について触れられていて、OAuthでは上記のユーザー情報の提供のための仕様が存在しないので足してるって感じです。
Notably, without profiling OAuth 2.0, it is incapable of providing information about the authentication of an End-User. 特に、OAuth 2.0 はプロファイリングを行わない限り、エンドユーザーの認証に関する情報を提供することができません
この辺りはOAuth認証()の話。
OpenID Connect implements authentication as an extension to the OAuth 2.0 authorization process. OpenID Connectは、OAuth 2.0認可プロセスの拡張として認証を実装します。
この一文は微妙な表現ですね。こいつのせいかもしれん。
まとめ
「OAuthは認可、OIDCは認証」の真意(?)とは、
「OAuthは認可、OIDCは(IdPが)認証(したユーザーの情報をやり取りするための仕様)」
って思っておくのが良いでしょう。
もしかしたら、これまで監修して責任はワイにあるなんて言ってきたAuth屋さんの本で違う言い方してるかもしれません。 ちょっと細かいこと忘れてしまったので、持ってない方は買ってもろて、年末年始に全冊確認して下さい。
「認証認可」というキーワードから一歩進むために必要な考え方と宣伝
上記のOIDCの部分をもうちょいしっかり説明しようと思うと、次のような前提知識が必要となります。
- サービスはそれぞれID管理を行っており、Identity Registerによるアイデンティティ情報の管理、Identity Lifecycleを意識した機能(新規登録やアカウントリカバリー、退会など)とSession Lifecycleを意識した機能(ログイン、ログアウトなど)を実装している。
- いわゆる本人確認と呼ばれる機能は次の2つのいずれかが行われている
- 身元確認(Identity Proofing): ユーザーが提示した情報をなんらかの方法で検証すること
- 当人認証(Authentication): 正規のユーザーであることを検証すること
- あるサービスのアイデンティティ情報を別のサービスに提供するのがID連携(Identity Federation)
OIDCはID連携のためのプロトコルであり、IdPが自身で管理しているアイデンティティの情報をRPに提供します。 そして、受け取ったRPはそれらを身元確認や当人認証に利用します。 仕様としてはサービス間のデータのやり取りが定められているOAuth 2.0に「アイデンティティ情報をどのように表現するか」といったIdentityレイヤーと呼ばれるものを加えた形となっています。
みたいな感じになります。
==ここから宣伝です。==
このような前提知識はどこに書いてあるのか、1/7に発売予定の私の本に書いてあります。
みんな大好き「認証・認可」と言うフレーズですが、現場の人間が実際に作らないといけないのはそれ以外のあれやこれを含めた「ID管理」の機能です。
— 👹秋田の猫🐱 (@ritou) 2025年12月11日
オンラインサービスのIDを支える機能や概念をXや記事などでいつも言ってるキーワードを使って紹介しているので、是非読んでみてください。 https://t.co/9WGsoTIdBc
ぜひお手に取ってみて下さい。
==宣伝終わり==
ではまた！
