前回に続く第２回ですが、今回は、OAuth2 / OIDC系とSAML2系の違いについて言及したいと思います（前回言及した、XML vs JSON部分の比較は除く）。
OAuth2 / OIDC系とSAML2系を比べると、SAML2系は、
- 仕様の組合せが自由な（≒ プロファイルの縛りが弱い）気がします。
- 従って、プロダクト間の連携は、個別対応になっていると思われます。
- XMLライブラリにも互換性の問題が恐らくあるものと思われますが、
プロダクト間連携が個別対応されているため、連携自体はできている。
みたいな現状だと思います。
それで、古くて著名なオープンなSSOプロトコルであるにもかかわらず、SP側へのライブラリ提供が進んでおらず、対応に苦労する。って話なんだと思います。まぁ、雑なSP側に勝手に連携コードを実装されないので、そういう意味でセキュアだ。みたいなことは言えそうですが、
「クロスドメイン認証が一般化してきて、
そういう時代でもなくなって来たよね。」
みたいな話はあるのかもしれません（現時点では、SP側は、ゲートウェイ等に集約しているし、IdP側は特定プロダクトにロックインされていると思います）。
あと、SAMLはバージョン2.0のリリース時期が、2005年3月と古くなってきていることもあり、OAuth2 / OIDC系と比べると、フレームワークなどの最新の技術慣行との不一致も出てきている気がします（若しくは、元々、考慮されていない）。私は、以下の点が気になりました。
...フレームワークの既定の動作では、ReturnUrlにはPOST転送が出来ないんですよね。なので、Request時のPOST-Bindingは、あまり実装したくないですね。また、今後、Same-Site Cookieとの関連も出て来るかも知れないらしいです（これについては、"response_mode = form_post"も影響があります）。
...色々と、大変そうですが、SAML2系は全体的にプロファイルでの縛りが弱い感じなので、近日、Metadataを実装して、SAML 2.0 Test Service Provider（SP）と、汎用認証サイト（IdP）との連携テストを予定しています。
＜参考＞
トップページ
お知らせ
開発基盤部会
汎用認証サイトにSAML2を大方実装しました（２）
