OpenID Connect/SAMLにおける多要素認証の強制は現実的か？

tech

はじめに

これはDigital Identity技術勉強会 #iddance Advent Calendar 2025の13日目の記事ですが、執筆が間に合わなかったので1日遅れで出ています。ここ最近このアドベントカレンダーは逆張りクソ野郎行為しかしてないのでたまには逆張りでない話を書きます。

多要素認証の浸透の裏返しとして「強制したい」が出てきた

このアドベントカレンダーに興味を持つ人にとって多要素認証はもはや当たり前になっているのではないかと思いますが（そうではない？物理デバイスを買わなくても認証アプリを使ってTime-Based OTPの設定とかから始めましょう！）、最近はエンタープライズ領域でも多要素認証が要件に入ってくることが増えてきています。その際に、新たに構築するSP/RPではパスワードを持ちたくないのでOpenID ConnectあるいはSAMLで認証したい、しかしIdPで多要素認証をしたことを強制したい、というようなことが出てくるでしょう。他にも多要素認証の強制に限らず、Authenticator Assurance Levelが一定以上であることを強制したい、みたいな要件もあるでしょう。

Q: エンタープライズだったら接続先IdPに設定を強制すればいいのでは？ A: 複数テナントに提供する場合、各テナントに設定をやってもらう必要があるので設定されてるかどうかを保証することができず、認証レベルが不十分な場合特定の機能にアクセスさせたくないみたいな場合に困る。

なおこの「認証レベルが不十分な場合特定の機能にアクセスさせたくない」みたいなのを解決するOAuthの仕様にOAuth 2.0 Step Up Authentication Challenge Protocolというものがあります。RFC (RFC 9470) はこちら、Authleteさんの解説記事はこちら。

理論的にはどうやるの？

OpenID ConnectとSAMLの両者に共通する Authentication Context Class Reference という概念があり、どのような認証が行われたかのクラス分類をSP/RPに伝えることが標準上はできます。OpenID ConnectではID Tokenに乗ってくる acr クレームに、SAMLの場合は RequestedAuthnContext で指定した上で Assertion 中の AuthnContext に AuthnContextClassRef が乗ってきます。実際に取りうる値はSAMLの場合はOASISのドキュメントに列挙してあり、OpenIDの文脈ではそのためにProvider Authentication Policy Extension(PAPE)というのが定められています。

じゃあ実際の対応状況は？

性質のいいIdPを自前で動かしているクライアントならばよいのですが、だいたいの場合IdPの運用を大手クラウドプロバイダに頼っているケースが多いのではないでしょうか。するとGoogleかMicrosoftが思いつきますが…

  • Google
    • GoogleのOpenID Connectのドキュメント
    • そのAIモード要約
      • "Google's OpenID Connect implementation does not publicly document support for specific acr_values (Authentication Context Class Reference values) in its discovery document or developer guides. The acr claim is generally an optional and voluntary parameter, and Google appears to manage authentication strength internally rather than exposing specific ACR values for clients to request. "
    • だめそう
  • Microsoft
    • AIモードの検索結果
    • 「多要素認証の強制」っぽいことが書いてあり有望そうに見えるが…
    • 一般的なMicrosoftのopenid-configuration
      • acr_values_supported がない
    • PowerPagesのOpenID Connect IdPの設定 へ誘導されているがこれはRPなのでは…？
    • "Custom Policies (Entra ID B2C): In B2C scenarios, acr_values can be handled within custom policies to trigger specific authentication steps or user flows. This often involves using Conditional Access Policies for MFA enforcement, which typically requires an Azure AD Premium P1 license."
      • 私は該当のライセンスを持つテナントを持っていないので試せていない
    • なので場合による、それでもできるかは未検証

というわけで大手クラウドプロバイダが対応しているかというと「対応してない寄りに構えたほうがいい」ように思います。このへんについて、特にMicrosoftの上のランクのライセンス持ってて検証したことあるよ！という方がいましたらコメントいただけると嬉しいです。

見る限りでAuth0は対応していて（Step-up Authenticationも対応してますね！）、IDaaSなどの認証認可プロダクトを専門に作っているところには実装されていそうですが、全員が使えるものという前提を置いてしまうとハマることになりそうです。関連して、各クラウドプロバイダは「 acr_values を受け取ることができる」に加えて「どのセットの acr_values なら返せるか」というのをなんとなくでもいいのでドキュメントに書いててもらえるとRP側としてはありがたいですね…（ .well-known/openid-configuration を見ろは確かにそうだけどそのサービスがどのネームスペースなら対応できるかどうかみたいなところはドキュメントにあると嬉しい）。