Resources

1. otkta - OAuth、OpenID Connect、SAMLの違い
2. Zenn - 認証と認可の超サマリ　OAuth とか OpenID Connect とか SAML とかをまとめてざっと把握する本
3. SAML入門

(1) より、

OpenID ConnectまたはSAMLを単独で使用することで、ユーザー認証を実現し、シングルサインオンを導入できます。どちらもログインを扱いますが、メリットとデメリットが異なります。

• OpenID Connectは、OAuth 2.0プロトコルをベースに構築されており、IDトークンと呼ばれる追加のJSON Web Token（JWT）を使用して、スコープやエンドポイントの発見など、OAuth 2.0が選択に委ねている部分を標準化しています。ユーザー認証に特化しており、消費者向けWebサイトやモバイルアプリでユーザーのログインを可能にするために広く利用されています。
• SAMLは、OAuthとは独立しており、JWTとは対照的に、XML SAMLフォーマットで認証するためのメッセージの交換に依存しています。一般的には、企業ユーザーが1回のログインで複数のアプリケーションにサインインするために使用されます。

SP-initiated なケースでは、

SP となるアプリケーションがやるべきは

(1) IdP で認証してくるように示す "SAML Request" を伴うレスポンス（IdP へのリダイレクトが発生）
(2) IdP からの "SAML Resonse" によって、UserAgent からリダイレクトされたリクエストを受け取る。ここに "SAML assertion" が含まれる
(3) SAML assertion を検証する。それは有効な IdP から来たのか／ユーザー情報があっているか、などを見る。OKなら認証済みとする

ポイントは、
(1) のリダイレクトレスポンスを生成した時点では SP 側はユーザーが誰かわからないし、そこで返した認証リクエストが最終的にどうなったのかを知るすべがないこと。
よって、(2) でやってくるリクエストはユーザーの身元も含めて必要な情報全部が含まれなければならない。

(2) を検証するために、

• 証明書。IdP の公開証明書を取得して保持しておき、SP に SAML response が来る (=2) たびにこの公開証明書を利用する。
• ACS (Access consumer Service) エンドポイント。SAML Response を受け取るためのエンドポイント。正しい IdP は、このエンドポイントを事前に知らなければならない。
• IdP にサインインするエンドポイント。SP が (1) でリダイレクト指示をする際に必要になるため、SP は事前にこの URL を知る必要がある。