OIDC入門&SAMLとの比較

Jan 20, 2024 08:20 · 2647 words · 6 minute read Security JWT

関わっているWebアプリの認証機能を近いうちにLDAPから移行します。移行先候補であるOIDCとSAMLについて調べました。

SAML
- 認証ステップ
OIDC
SAMLとOIDCの違い
OIDCの認証方法
OIDCのセキュリティ
OAuth&OIDCの解説動画（入門編）
最後に
参照

SAML

Security Assertion Markup Language（SAML）の略で、認証に関する仕様です。 XML形式で認証プロバイダー（IdP）とサービスプロバイダー（SP）がやり取りします。

認証ステップ

(1)メタデータをやり取りし、Service ProviderとIdP（認証プロバイダー）が互いを理解する

メタデータには、下記が含まれる

暗号化に使う公開鍵
サポートされる暗号化アルゴリズム
エンドポイントURL（SAMLメッセージの送信先）
サポートされる接続方法
サポートされるXML属性フォーマット

(2)ユーザーがログインしようとすると、SPはIdPにSAML AuthnRequestと呼ばれる認証リクエストを送信する

(3) IdPはユーザー認証をし、SAMLアサーションと呼ばれるエンコードされたSAMLレスポンスをSPに返す

(4)SPはSAMLアサーションというXMLにしたがってユーザーのアクセス許可や制御をする

OIDC

OpenID Connect（OIDC）の略で、こちらも認証に関する仕様です。 OAuth2.0をベースに構築されており、JSONベースのJWTでIdPとSPがやり取りします。 OIDCには複数種類の認証方法があります。

SAMLとOIDCの違い

OIDCの方がSAMLよりも新しい仕様で、SPA（シングルページアプリケーション）やスマートフォンアプリへ実装が簡単です。また、JWTを使ったOIDCの方がXMLを使うSAMLよりも処理が軽量です。

OIDCはOAuth2.0に基づいているので、多くの脅威モデルやセキュリティの検討事項が文章化されているのもありがたいポイント。

RFC 6819 - OAuth 2.0 Threat Model and Security Considerations (ietf.org)

後発の仕様であり、より現代の需要にマッチしているので、基本的にはOIDCを使うのが良さそうです。しかしながら、先行するSAMLの方が世間には浸透しているため、SAMLしか対応していない認証システムと連携が必要な場合や、長期間の運用実績を重視する場合はSAMLを選ぶとよいでしょう。

OIDCの認証方法

OIDCには3つの認証方法があります。

暗黙的フロー The Implicit Flow

JavaScriptのSPAアプリなど、バックエンドがないシステムで使う方法です。

クライアントは、所望のリクエストパラメータを含む認証リクエストを準備します。
クライアントはそのリクエストを認可サーバーに送信します。
認可サーバーはエンドユーザーを認証します。
認可サーバーはエンドユーザーの同意/認可を取得します。
認可サーバーはエンドユーザーをIDトークンおよび、要求された場合はアクセストークンとともに、クライアントに戻します。
クライアントはIDトークンを検証し、エンドユーザーのサブジェクト識別子を取得します。

Final: OpenID Connect Core 1.0 incorporating errata set 2 > 3.2. Authentication using the Authorization Code Flow

認証フロー The Authorization Code Flow

サーバーなどのバックエンドをもつシステムで使う方法です。

クライアントは所望のリクエストパラメータを含む認証リクエストを準備します。
クライアントはそのリクエストを認可サーバーに送信します。
認可サーバーはエンドユーザーを認証します。
認可サーバーはエンドユーザーの同意/認可を取得します。
認可サーバーはエンドユーザーを認可コードとともにクライアントに戻します。
クライアントはトークンエンドポイントで認可コードを使用してレスポンスをリクエストします。
クライアントはレスポンス本体に含まれるIDトークンとアクセストークンを受け取ります。
クライアントはIDトークンを検証し、エンドユーザーのサブジェクト識別子を取得します。

Final: OpenID Connect Core 1.0 incorporating errata set 2 > 3.1. Authentication using the Authorization Code Flow

ハイブリッドフロー The Hybrid Flow

暗黙的フローと認証フローを組み合わせた方法です。

クライアントは所望のリクエストパラメータを含む認証リクエストを準備します。
クライアントはそのリクエストを認可サーバーに送信します。
認可サーバーはエンドユーザーを認証します。
認可サーバーはエンドユーザーの同意/認可を取得します。
認可サーバーはエンドユーザーを認可コードおよび、Response Typeによっては1つまたは複数の追加パラメータとともにクライアントに戻します。
クライアントはトークンエンドポイントで認可コードを使用してレスポンスをリクエストします。
クライアントはレスポンス本体に含まれるIDトークンとアクセストークンを受け取ります。
クライアントはIDトークンを検証し、エンドユーザーのサブジェクト識別子を取得します。

Final: OpenID Connect Core 1.0 incorporating errata set 2 > 3.3. Authentication using the Hybrid Flow

OIDCのセキュリティ

OIDCはOAuth2.0を基にしているため、OAuthに関する脆弱性の影響を受けます。また、バックエンドを持たない環境で使う暗黙的フローにはセキュリティ上のリスクがあります。セキュリティ関連の推奨事項を考慮して実装すると良いでしょう。

参照

OAuth&OIDCの解説動画（入門編）

参考になりそうな解説動画です。

最後に

OIDCとSAMLについて学びました。これらの認証方法を使うための便利なライブラリは複数ありますが、ライブラリを使うにしても基本的な知識を知っておかなければなりません。

基本的な知識と、追加で調査したい場合の参照先がわかったので、適宜知識を深めながら認証機能の移行をしたいと思います。