SAMLとOpen ID Connectの使い分け方
*Open ID Connectは以降OIDCと省略して記載します。
イントロ
自作しているアプリにログイン機能を追加したい時や、２つのプラットフォーム(AWSやAzureなど)のIDを連携したい時、SAMLやOIDCというキーワードをよく見かけると思います。OIDCとSAMLは両方とも、ユーザーの認証を「委譲」するプロトコルですが、これらはどのように使い分ければ良いのしょうか？
私はアプリ開発していた当時この疑問を感じ、その際に調査した内容や思ったことを今回まとめたいと思います。
一般的な結論
まず、一般的に「SAML OIDC 違い」とグーグル検索して出てくる記事を見てみましょう。
この記事では使い分けは以下のように書かれております。
いつOIDCを使用し、いつSAMLを使用するべきか?
OIDCとSAMLは、どちらも固有の機能を持つ強力な認証テクノロジーです。組織でどちらを使用するべきかは、特定のニーズに基づいて決定します。次のように考えてください。
・IDプラットフォームを迅速に設定したい場合は、ためらわずSAMLではなくOIDCを選択します。基本的なOIDCソリューションの実装は、膨大なXML処理が必要なSAMLと比べてはるかに簡単です。
・多くのモバイルアプリケーションとシングルページアプリケーションを含むAPI中心のアーキテクチャがある場合は、OIDCを使用します。はるかに効率的で、相互運用可能なエクスペリエンスが保証されます。
・長年の実績がある、成熟した標準を実装したい場合は、SAMLを選択します。機能が豊富であり、しっかりと対応でき、10年以上にわたってエンタープライズネットワークの定番です。
この説明で「なるほど！」と納得できますでしょうか？「IDプラットフォームを迅速に設定したい場合」、「長年の実績がある、成熟した標準を実装したい場合」などと運用や歴史的な背景のみしか語られておらず、技術的な裏付けはありません。私が求めているのは、「セキュリティ的に堅牢性が求められる場合はSAMLで、そうで無い場合はOIDC。なぜなら。両者の仕組みの違いは・・・」みたいな説明です。
しかも、この記事が特別なわけではなく、どの記事を見てもこんな感じで解説されています。私は全然納得できませんでした。(調査が完了した今、この文章を読むと「確かにこう書くしかないよなぁ」とも思います。)
当時、私は「SAMLやOIDCの理解が足りてないのかな」と思い、両者の処理やフローなどを詳細に調査しました。しかし調べた結果、XMLやJSONなどの細かい違いがあれど、本質的にやっていることは同じでした。
（調査時に分かりやすかった書籍を紹介します。）
とはいえ、SAMLやOIDCの仕組みを知ることは、実装するうえで必要なので必ず理解しましょう！ただ、きちんと理解しても、両者を使いわけられるようにはなりません。
私が出した結論
*ここからは事実というより、私が納得するための妄想も含みます。
私が出した結論は以下となります。
「両者に明確な機能的使い分けは無い。ただし、成り立ちの過程からよく使われる場面が異なる。」
タイトルと矛盾してすみません。これを理解する上で重要なポイントは２点、「発足時期」と「実装の複雑さ」です。両者の違いを表にまとめました。(年代は正確で無い可能性があります)
$$
\begin{array}{|l|l|l|} \hline
& SAML & OIDC \\ \hline
発足時期 & 2005年頃 (先) & 2014頃(後) \\ \hline
実装の複雑さ & 複雑 & 簡単 \\ \hline
\end{array}
$$
SAMLが先に登場し、その後にOIDCが登場した。そして、SAMLは実装が複雑で、OIDCは簡単ということです。
つまり、XXXの時はSAML、XXXの時はOIDCみたいな機能的な使い分けは存在せず、実装の複雑性の観点からOIDCを使えるならいつでもOIDCを使う。使えない時は仕方なくSAMLを使うということです。
では、SAMLはなぜ現在も淘汰されていないのでしょうか？これは歴史的な背景(発足時期)が関係すると思われます。
*ここからは私の推測(妄想)要素が強くなります。
SAMLが提唱された頃、大手のプラットフォーム(AWS、Azureなど)はSAMLに対応した。この対応は「プラットフォーム同士の認証連携」と「プラットフォームとエンドユーザーが独自に開発するアプリとの認証連携」の2つがあったと思います。後にSAMLの実装の複雑さからOIDCが注目された。プラットフォームはユーザーを複雑な実装から解放するために、エンドユーザーの独自開発アプリに対してはOIDCに対応した。しかしプラットフォーム同士の連携はどうでしょうか？プラットフォーム同士のSAMLの実装はすでに完了しており、ユーザーはSAMLで必要なパラメーターを設定するだけで、SAMLの実装複雑性の影響は受けません。このため、プラットフォーム同士の認証連携ではSAMLが使われている（残ってしまっている）のだと思います。
結果として以下図ように、大手プラットフォーム同士の連携認証はSAML、エンドユーザーが新規で開発するアプリに対してはOIDCになってしまっているのだと思います。
ポイントは、この使い分けが機能や用途による違いではなく、成り立ちの過程でこれで落ち着いているだけということです。プラットフォームたちが、みんなでSAMLをやめてOIDCだけにしよう！と決めれば、SAMLは淘汰されると思います。(ユーザーに設定の変更を強要するので、費用対効果的に絶対に起こらないと思いますが)
この習慣から、Auth0のような後発のプラットフォームであっても、この構図を倣わざる負えないという事態が発生しているのだと思います。
さて、ここまで読んで、冒頭で紹介した以下の一般的な使い分けの指針をみると、納得の度合いが変わってきませんでしょうか？確かに間違っては無いが、もっと上手く書けよと思っていただけたら幸いです。
いつOIDCを使用し、いつSAMLを使用するべきか?
OIDCとSAMLは、どちらも固有の機能を持つ強力な認証テクノロジーです。組織でどちらを使用するべきかは、特定のニーズに基づいて決定します。次のように考えてください。
・IDプラットフォームを迅速に設定したい場合は、ためらわずSAMLではなくOIDCを選択します。基本的なOIDCソリューションの実装は、膨大なXML処理が必要なSAMLと比べてはるかに簡単です。
・多くのモバイルアプリケーションとシングルページアプリケーションを含むAPI中心のアーキテクチャがある場合は、OIDCを使用します。はるかに効率的で、相互運用可能なエクスペリエンスが保証されます。
・長年の実績がある、成熟した標準を実装したい場合は、SAMLを選択します。機能が豊富であり、しっかりと対応でき、10年以上にわたってエンタープライズネットワークの定番です。
以上、SAMLとOIDCの使い分けの話でした。私の妄想が多分に含まれている考察ですので、誤っている部分があればご指摘お願いします。