Webアプリにステップアップ認証を設定する

ステップアップ認証を使うと、さまざまなタイプのリソースへのアクセスを許可するアプリケーションが、機密情報にアクセスしたり特定のトランザクションを実行したりするユーザーに、より強力なメカニズムを使用して認証するよう要求できます。

例えば、ユーザーは、多要素認証（MFA）を使用して本人確認を行った後でなければ、機密データを含むビューへのアクセスやパスワードのリセットが許可されない場合があります。

Webアプリでステップアップ認証を実行するには、Webアプリが要求した際にユーザーにMFAによる認証を求めるアクションを作成し、ユーザーが制限されたページにアクセスしようとした際にMFAに対するIDトークンクレームをチェックし、MFAがそのクレームに含まれていない場合はユーザーにチャレンジを送信するようにします。

ユーザーがログインすると、ユーザーのセッションに関連する情報が含まれたIDトークンがクレームとして渡されます。関連するクレームは、ログイン時に使用された認証方法を表す文字列のJSON配列であるamr（認証方法参照）です。これはIDトークンのペイロードに示され、値mfaを含んでいる必要があります。

その値には、事前に定義された認証方法参照値が含まれることがあります。この値にはmfa以外のクレームを含めることができるため、検証時には、その存在をテストするとともに、mfaの値が含まれているか内容を調べる必要があります。

制限されたページにユーザーがアクセスしようとし、トークンが、ユーザーがMFAで認証されていないことを示した場合、アクションを使用してMFAをトリガーするように設定した認証を再トリガーすることができます。ユーザーが2つ目の要素を入力すると、amrクレームを含む新しいIDトークンが生成され、アプリに送信されます。

1. IDトークンを取得します。

2. このトークンの署名を検証します。これは、トークンの送信者が自称のとおりであることを検証し、メッセージが途中で変更されていないことを保証するために使用されます。

3. 以下のクレームを検証します。

   クレーム	説明
   exp	トークンの有効期限
   iss	トークン発行者
   aud	トークンの意図された受信者
   amr	amrがペイロードに存在しないか、mfaという値を含まない場合、ユーザーはMFAでログインしませんでした。amrがペイロードに存在し、mfaという値を含む場合、ユーザーはMFAでログインしました。

次の使用例を除き、amrクレームは必須です。

1. ホスト型ログインフローでは、ユーザーがMFAチャレンジに合格した場合にのみ、amrクレームがIDトークンに挿入されます。アプリがサイレント認証を使用しているか、または新たに発行されたIDトークン用のリフレッシュトークンを使用している場合、ユーザーが事前にMFAによるログインを完了しているため、amrクレームは存在しません。

2. MFA APIが発行したトークンにamrクレームは含まれていません。amrクレームは、ユーザーがIDトークンを受け取る際に使用された認証方法にフラグを設定します。MFA API認証プロセスでは、アプリケーションが認証フローを制御し、必要に応じてMFAを強制できます。

以下の例では、ユーザーがMFAで認証した場合とそうでない場合のIDトークンのペイロードに含まれる可能性のある値を比較できます。

{
    "iss": "https://{yourDomain}/",
    "sub": "auth0|1a2b3c4d5e6f7g8h9i",
    "aud": "{yourClientId}",
    "iat": 1522838054,
    "exp": 1522874054,
    "acr": "http://schemas.openid.net/pape/policies/2007/06/multi-factor",
    "amr": [
        "mfa"
    ]
}

{
    "iss": "https://{yourDomain}/",
    "sub": "auth0|1a2b3c4d5e6f7g8h9i",
    "aud": "{yourClientId}",
    "iat": 1522838054,
    "exp": 1522874054
}

次のシナリオでは、Webアプリがユーザー名とパスワードでユーザーを認証します。給与データを表示する特定の画面にアクセスしたいユーザーは、Guardianのプッシュ認証で認証を受ける必要があります。

このシナリオでは、Dashboardで以下の項目を設定する必要があります。

• Webアプリを登録する。

• データベース接続を作成する。

• MFAを有効にしてプッシュ通知を使用する。

Webアプリが要求した際に、MFAによる認証のチャレンジをユーザーに送信するアクションを作成します。［Dashboard］ > ［Actions（アクション）］ > ［Flows（フロー）］に移動し、以下の内容を含むアクションを作成します。

exports.onExecutePostLogin = async (event, api) => {
 const CLIENTS_WITH_MFA = ['REPLACE_WITH_YOUR_CLIENT_ID'];
 // run only for the specified clients
 if (CLIENTS_WITH_MFA.includes(event.client.client_id)) {
 // ask for MFA only if the web app said so in the authentication request
 if (event.transaction?.acr_values.includes('http://schemas.openid.net/pape/policies/2007/06/multi-factor')) {
 api.multifactor.enable('any', { allowRememberBrowser: false });
 }
 }
}

• CLIENTS_WITH_MFA変数には、このアクションを適用するアプリケーションのクライアントIDが含まれています。必要なければ、この変数（および、その後のif条件文）は削除できます。

• event.transaction.acr_valuesプロパティは、認証コンテキストクラス参照（acr）を含む文字列の配列です。これはオプションのプロパティで、アプリケーションが認可サーバーへの認証要求に含める場合にのみ存在します。この例では、当社のWebアプリは認証要求にこのプロパティを含めますが、MFAでまだ認証されていないユーザーが給与情報にアクセスを試みた場合に限られます。当社のWebアプリにこれが含まれている場合、http://schemas.openid.net/pape/policies/2007/06/multi-factorの値が設定されます。これは、認可サーバーにMFAを要求することを示しており、コードで設定されているapi.multifactorプロパティの値により、テナントで構成されている利用可能な方法のいずれかを使用してユーザーにMFAチャレンジを送信します。api.multifactor.enable()に関する詳細については、「アクションのトリガー：ログイン後のAPIオブジェクト」をお読みください。

• http://schemas.openid.net/pape/policies/2007/06/multi-factorポリシーでは、エンドユーザーが複数の認証要素（MFA）を提供することでOpenIDプロバイダーに認証を行う認証メカニズムを定義しています。詳細については、OpenIDプロバイダー認証ポリシー拡張機能1.0をお読みください。

ユーザーが制限付きの給与情報ページにアクセスしようとした際に、MFAを使用して認証済みであることを確認するようにアプリを設定します。（ユーザーがMFAで認証済みの場合、IDトークンのクレームには、値がmfaであるamrクレームが含まれます）。ユーザーがすでにMFAで認証済みの場合、Webアプリは制限付きのページを表示します。そうでない場合Webアプリは、acr_valuesパラメーターを含む新しい認証要求を送信します。このパラメーターの値は http://schemas.openid.net/pape/policies/2007/06/multi-factorで、これによってアクションがトリガーされます。

このシナリオにおけるWebアプリは認証に認可コードフローを使用するため、要求は以下のようになります。

https://{yourDomain}/authorize?
        audience=https://{yourDomain}/userinfo&
        scope=openid&
        response_type=code&
        client_id={yourClientId}&
        redirect_uri={https://yourApp/callback}&
        state={yourOpaqueValue}&
        acr_values=http://schemas.openid.net/pape/policies/2007/06/multi-factor

ユーザーがMFAで認証すると、Webアプリは認可コードを受け取ります。この認可コードは、新しいIDトークンと交換する必要があります。このIDトークンには、値がmfaのamrクレームが含まれているはずです。IDトークン用のコードを交換する方法については、「認可コードフローを使用してログインを追加する」をお読みください。

このシナリオでは、トークンの署名（jwt.verify）を検証し、トークンをデコードし、ペイロードにamrが含まれているかどうかを確認し、含まれている場合は結果をコンソールにログ出力するJSON Webトークンサンプルコードを使用して検証を実行します。

const AUTH0_CLIENT_SECRET = '{yourClientSecret}';
const jwt = require('jsonwebtoken');

jwt.verify(id_token, AUTH0_CLIENT_SECRET, { algorithms: ['HS256'] }, function(err, decoded) {
  if (err) {
    console.log('invalid token');
    return;
  }

  if (Array.isArray(decoded.amr) && decoded.amr.indexOf('mfa') >= 0) {
    console.log('You used mfa');
    return;
  }

  console.log('you are not using mfa');
});

• IDトークン
• ルールのユースケース
• JSON Webトークン
• APIのステップアップ認証を構成する