【Okta】Authentication method chainを使って認証方法を完全に制御する！

こんにちは！たつみんです！

Okta管理者としてユーザーにどのような認証方法を使ってもらいたいかを考えることは重要です。これまでOkta Identity Engineでは、どの認証方法を使用させるかしか指定できず、順番を指定することはできませんでした。

今日は、Version 2024.09.0でEarly AccessとしてリリースされたAuthentication method chainによって認証ポリシーのカスタマイズ方法やどのようなメリットがあるかを実現できることをご紹介します。

はじめに

まずは現状の確認です。Authentication policyでAny 2 factor typesを選択した場合は下図のようにKnowledge / Biometric factor typesと、Additional factor typesそれぞれでユーザーが利用できる可能性がある認証方法が表示されています。

つまり、組み合わせとしてはPasswordとGoogle AuthenticatorやPasswordとFIDO2 (WebAuthn)のようにさまざまな可能性があります。

組織によっては最初は必ずFIDO2 (WebAuthn)による認証を実施しその次にパスワードを入力させたいというニーズがあります。　このような場合にAuthentication method chainを利用することで実現することができます。

設定方法

はじめにOkta Admin Console>Settings>FeaturesからAuthentication Method Chainを有効化します。

任意のAuthentication policyで既存のRuleもしくはAdd ruleから編集画面を開きます。

User must authenticate withで『Authentication method chain』を選択します。

下図のようにFirst authentication methodとORで認証方法をそれぞれ選択することができます。Add stepから3番目の認証方法追加することもできます。

Add authentication method chainから別の方法を設定することも可能です。

最終的に下図のような設定としました。

実際にアプリケーションにアクセスしようとすると以下のような画面が表示され、まずパターン1のSecurity Key or Biometric Authenticatorか、パターン2のGoogle Authenticatorのどちらかを選択する表示となります。

Security Key or Biometric Authenticatorを選択するとFIDO2 (WebAuthn)を利用した認証を実施後にパスワードを入力し、さらにOkta VerifyのTOTPによる認証を実施する必要がありました。

まとめ

Authentication method chainを利用することでユーザーが認証を実施する際の順番を含め細かく設定することができました。また最大で3ステップの認証を求めることができます。

メリットとして一般社員はさまざまな認証方法を利用できるが、コールセンターのようにそもそも認証方法が限られるような場合にユーザーに特定の認証方法のみを表示することでよりシンプルで摩擦の少ないログイン体験を提供することができるということが考えられます。また、パスワードを全く利用させないことによるパスワードを基点とした攻撃の低減への貢献などが考えられます。

細かいカスタマイズを柔軟にできるのはOktaのいいところですね。

それではまた別の記事でお会いしましょう👋