OAuth、OpenID Connect、SAMLとその違いについて大雑把にまとめると

はじめに

WEBシステムでよく使用されるOAuth、OpenID Connect、SAMLとその違いについてざっくり概要をまとめました。
できるかぎり簡潔に書いたつもりですが本当にざっくりまとめたので、もっと詳しいことが知りたい方は最後の参考文献を読まれることをお勧めします。

基礎知識

認証と認可の違い

認証

アカウントを識別する識別子(ユーザID、メールアドレスなど)とそれに紐づくクレデンシャルと呼ばれる認証に使用する情報(パスワード、指紋、FIDOなど)を使用してアカウントを使用しようとしているユーザーがアカウントの所有者であるか確認すること。

認可

コンテンツに対するアクセス権の付与。
画面に対するアクセス権や、コンテンツに対する編集権限などが例として挙げられます。
ユーザー一人に対して個別にアクセス権を設定されることはあまりなく、ロールに対して権限が設定され、ユーザーはロールを割り振られる形で制御されることが多いです。

SSOとは

1つのシステムで認証を行うことで複数のWEBやクラウドのサービスにアクセスできる仕組みのこと。
実現方法は複数あり、仕組みもフェデレーション方式、リバースプロキシ方式など様々です。
例：Googleにログイン後、ドライブやYoutubeにもログイン状態でアクセスできるようになるなど

従来のシステムごとにID、パスワード等で認証を行うよりもユーザー・管理者の負担低減やセキュリティの向上が期待できると言われています。

OAuthとは

OAuthは認証に使用されることも多いですが、本質的には認可のためのフレームワークです。
ユーザーが所持するアプリケーション内のコンテンツへ、別のアプリケーションによるアクセスを許可するものになります。

OAuth 2.0 は, サードパーティーアプリケーションによるHTTPサービスへの限定的なアクセスを可能にする認可フレームワークである
https://openid-foundation-japan.github.io/rfc6749.ja.html

外部のアプリケーションからAPIなどのHTTPサービスを使用して、一部の許可された操作を行うことができる認可フレームワークです、と言い換えるともう少しとっつきやすくなるでしょうか。

これを使用すると、外部のアプリケーションがHTTPサービスのコンテンツ(例えばgoogleのドライブ上のファイル等)に対し、認可画面されたアクセス権と有効期限の範囲内で処理を行うことができます(閲覧、アップロード、ダウンロードなど)。
このときユーザーはgoogleなどのHTTPサービスのログイン情報を外部のアプリケーションに渡す必要がありません。

OpenID Connectとは

SSOを実現する仕組みの一つで、OAuth 2.0を認証のために拡張させたものがOpenID Connectです。
ユーザーのID情報を連携する仕組みでもあります。
OpenID Connectはエンドユーザー、OpenID Provider と Relying Party という三者で成り立ちます。
Relying Partyの認証が必要な画面にユーザーがアクセスした際、OpenID Providerに対して認証(認可)リクエストを行います。このとき表示された認証・認可画面でユーザーが操作を行い、OpenID Providerがレスポンスを返します。
このレスポンスに認可コードが含まれます。Relying Partyでレスポンスから認可コードを取得してOpenID Providerに対してトークンリクエストを行います。OpenID ProviderはトークンをRelying Partyに返却し、Relying Partyはログイン後の画面など任意の画面をユーザーに表示したり、OpenID Providerに対してユーザー情報取得リクエスト等をします。

SAMLとは

Security Assertion Markup Languageの略で、「サムル」と読みます。
SSOを実現するフェデレーション方式の仕組みの一つで、認証情報の規格を指します。
※現在は2005年に制定された2.0が最新

SAML認証はユーザー、SPとIdPという三者で成り立ちます。
ユーザーは利用者、SP(サービスプロバイダー)は認証の連携を行う各システム、IdPが認証を行い認証情報やユーザー情報をSPに提供するシステムです。
認証を行うには、IdPとSPは事前にお互いを登録しておく必要があります。

SP-initiatedでSAML認証を行う場合、ユーザーはSPにアクセス、ログインする際に認証を行いますが、認証を行う際に表示されるのはだいたいIdPの認証画面になります。IdPで認証した結果とアサーションと呼ばれる属性情報が返され、SPのログインが許可されるという流れです。
IdPからユーザー情報を取得する場合、この属性情報に含まれるAttribute Statementsでユーザーに紐づく情報を渡されます。

IdP-initiatedでSAML認証を行う場合、ユーザーはSPにアクセスする前にIdPの認証画面から認証を行います。多くの場合、IdPで認証した後に表示されるハブページから各サービスにアクセスする流れです。アクセスしたときにはSPのサービスにログインが済んでいます。この時バックグラウンドで認証リクエストと認証レスポンスがやりとりされています。

OAuth、OpenID Connect、SAMLの違い

OAuthは認可のためのフレームワーク。
認証として使用する場合、認証時の情報（だれがいつどのように認証したか）ユーザー情報を提供するための手段はOAuth2.0では定められていないため、HTTPサービス側で独自にそれらの情報を取得するAPI等を提供しない限り、サードパーティ側でそれらの情報を取得できないという欠点があります。

OpenID ConnectはOAuth 2.0を拡張したもので、SSOを実現するフェデレーション方式の仕組みの一つ。
認証後にトークンを発行し、トークンを使用してユーザー情報の取得をはじめとするコンテンツへのアクセスを行います。
OAuth2.0を拡張したものなので、OpenID Providerの認証だけでなくそのあとのコンテンツへのアクセスをセットで運用するための機能が含まれています。
また、トークンレスポンスのIDトークンには認証時の情報（だれがいつどのように認証したか）が、ユーザー情報取得レスポンスにはユーザー情報が含まれています。

SAMLは認証情報の規格で、SSOを実現するフェデレーション方式の仕組みの一つ。
IdPで認証を行い、認証結果とともにアサーションと呼ばれる属性情報を返します。
OpenID Connectよりも認証が完了するまでのステップが短いですが、認証の規格なのでSSO連携されている他のアプリケーションのコンテンツへのアクセスはSPごとに個別に仕組みを用意する必要があります。

参考文献

• 雰囲気で使わずきちんと理解する！整理してOAuth2.0を使うためのチュートリアルガイド
  Auth屋　インプレスR&D
• OpenID Connect入門: 概念からセキュリティまで体系的に押さえる
  土岐 孝平
• SAML入門
  廣瀬 翔遥　インプレスR&D
• Software Design (ソフトウェアデザイン) 2020年11月号
  技術評論社