こんにちは、ネクストモード株式会社 テクニカルサポート担当です。
前回の記事で Salesforce の二重プロンプトを回避するために、Oktaで AMR を設定する方法と SAML Tracer で確認しました。今回の記事では AMR について Okta FastPass 以外のパターンも確認しながらもうすこし AMR について深ぼってみます。
前回の記事はこちら
AMR は Authentication Method Reference の略称で、ユーザーがどの認証方式で認証したかを示すクレームです。RFC 8176 では、この AMR クレームで使用する値(例： pwd、otp、mfa など)が定義されています。
私が観測できた AMR 値について以下の表にまとめました。
以降の検証結果は、この表の値が どの組み合わせで返るか という観点で整理します。
| AMR値 | 種別 | 意味 |
|---|---|---|
| phr | 別仕様（後述） | フィッシング耐性を示す意図で用いられることがある |
| okta_verify | Okta独自 | Okta Verify を用いた認証 |
| pop | RFC 8176 | 鍵の所持の証明 |
| swk | RFC 8176 | ソフトウェアベースのセキュリティキー |
| mfa | RFC 8176 | 多要素認証 |
| pwd | RFC 8176 | パスワード |
| otp | RFC 8176 | ワンタイムパスワード |
Okta のさまざまな認証方法で観測される AMR 値は以下のとおりです。
phr と okta_verify が観測できます。
pop が観測できます。
pop が観測できます。
swk と okta_verify が観測できます。
swk と mfa と pwd と okta_verify が観測できます。
mfa と otp と pwd と okta_verify が観測できます。
ここまでの項目の中で phr と okta_verify は RFC 8176 に掲載されている初期値セットには含まれません。そのため、ベンダー固有、または別仕様に基づく値として扱うのが安全です。
okta_verify は名前からも分かる通り Okta 固有の値と考えられます。phr については、RFC 8176 の AMR 値というより ACR（Authentication Context Class Reference）側で使われる値として、OpenID の別仕様（OpenID Connect Extended Authentication Profile (EAP) ACR Values 1.0）で定義があります。
phr は「フィッシング耐性（phishing-resistant）」相当の認証強度を示す ACR 値として説明されています。なお phr が AMR に出てくる理由については、RFC 8176 だけからは断定できません。実際に観測されることから、Okta が phr（phishing-resistant を示す ACR 側の語彙）に相当する情報を、実装上 AMR にも含めて返している可能性があります。
そのため本記事では、phr を製品実装に依存する値として位置づけて解釈します。
興味深い点として、Salesforce のドキュメントには、AMR に okta_verify が含まれている場合、二重プロンプトを発生させない旨が記載されています。これは Okta と Salesforce の2社間で密接な連携が行われていることを示す好例です。
このようなベンダー固有の AMR 値を活用することで、特定のサービス間でよりスムーズな認証体験を実現できます。okta_verify という値は、単なる認証方法の記録にとどまりません。二重プロンプトの回避という実際のビジネス要件を満たすための重要な役割を果たしています。
本記事では、Okta で観測される AMR(Authentication Method Reference)の値を、さまざまな認証方式ごとに確認しました。AMR は RFC 8176 で標準的な値が定義されていますが、phr や okta_verify のように、ベンダー固有の値や別仕様由来の値も含まれることがわかりました。
phr は OpenID Connect Extended Authentication Profile (EAP) ACR Values 1.0 でフィッシング耐性を示す ACR 値として定義されています。一方で、Okta では AMR に phr が含まれて返るケースが観測されており、phr は 製品実装に依存する値として扱うのが妥当といえます。
okta_verify についても RFC 8176 には含まれず、Okta 環境では Okta Verify を用いた認証を示す意図で使われていると考えられます。
Okta がこのように詳細な AMR 値を SP(RP)に連携するメリットは、アプリケーション側で認証強度やリスクベースの判断を柔軟に行える点があると考えられます。たとえば、phr が含まれていればフィッシング耐性のある認証が実施されたことが分かり、高セキュリティが求められる操作を許可する判断材料になります。
今回のように、実際に SAML Tracer を使って観測される値を確認し、仕様書と照らし合わせながら「この値はどこから来たのか？」「なぜこの組み合わせなのか？」と仮説を立てて調べるプロセスは、とても面白く学びの多い作業です。仕様の奥深さや製品実装の工夫に触れることで、認証の仕組みへの理解が一層深まります。ぜひ皆さんも、実際の環境で AMR や ACR の挙動を観測してみてください！