メインコンテンツへスキップ
ステップアップ認証を使用すると、異なる種類のリソースへのアクセスを提供するアプリケーションで、機密情報へのアクセスや特定のトランザクションの実行時に、より強力な認証方式をユーザーに要求できます。 たとえば、ユーザーが機密データを含むビューにアクセスしたりパスワードをリセットしたりできるのは、 (MFA) を使用して本人確認を行った後に限られる場合があります。 Web アプリでステップアップ認証を実現するには、Web アプリから要求があったときに MFA での認証をユーザーに求める Action を作成し、ユーザーが制限付きページにアクセスしようとした場合は、MFA に関する の クレーム を確認して、その クレーム に MFA が含まれていなければユーザーに認証を求めます。

​
MFA の IDトークンを検証する

ユーザーがログインすると、ユーザーのセッションに関連する情報をクレームとして含む IDトークン を取得します。ここで関連するクレームは amr (authentication methods reference) で、ログイン時に使用された認証方法を示す文字列の JSON 配列です。このクレームは IDトークンのペイロードに含まれている必要があり、値 mfa を含んでいなければなりません。 この値には、事前定義された Authentication Method Reference Values のいずれかが含まれる場合があります。mfa 以外の値が含まれることもあるため、検証時には amr が存在することを確認し、その内容に mfa が含まれているかも確認する必要があります。 ユーザーが制限されたページへのアクセスを試みた際に、トークンからそのユーザーが MFA で認証していないことがわかった場合は、認証を再度トリガーできます。この認証は、Action を使用して MFA がトリガーされるように設定されています。ユーザーが 2 つ目の認証要素を提供すると、amr クレームを含む新しい IDトークンが生成され、アプリに送信されます。
  1. IDトークンを取得します。
  2. トークンの署名を検証します。これにより、トークンの送信者が正当な送信元であること、およびメッセージが途中で改ざんされていないことを確認できます。
  3. 次のクレームを検証します。
クレーム説明
expトークンの有効期限
issトークンの発行者
audトークンの想定受信者
amrペイロードに amr が存在しない場合、または値 mfa を含まない場合、そのユーザーは MFA でログインしていません。ペイロードに amr が存在し、値 mfa を含む場合、そのユーザーは MFA でログインしています。

​
AMR クレームの例外

amr クレームは、次のユースケースを除き必須です。
  1. ホスト型ログインフローでは、ユーザーが MFA チャレンジを正常に完了した後にのみ、amr クレームが IDトークンに追加されます。アプリケーションが新たに発行される IDトークンに対してサイレント認証またはリフレッシュトークンを使用する場合、ユーザーは以前に MFA でログインを完了しているため、amr クレームは含まれません。
  2. MFA API で発行されたトークンには amr クレームは含まれません。amr クレームは、ユーザーが IDトークンを受け取る時点で使用された認証方法を示します。MFA API の認証プロセスでは、アプリケーションが認証フローを制御するため、必要に応じて MFA を強制できます。
以下の例では、ユーザーが MFA で認証した場合としていない場合で、IDトークンのペイロードに含まれうる値を比較できます。

​
例: MFA がある場合の値

​
例: MFA を使用しない値

​
シナリオ: プッシュ通知を使用する給与データ

次のシナリオでは、Web アプリが username とパスワードを使用してユーザーを認証します。給与データを表示する特定の画面にアクセスする一部のユーザーは、Guardian のプッシュ認証要素による認証が必要です。

​
前提条件

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

​
Action を作成する

Web アプリから要求されたときに、ユーザーに MFA による認証を求める Action を作成します。Dashboard > Actions > フロー に移動し、次の内容を含む Action を作成します。 
exports.onExecutePostLogin = async (event, api) => {
 const CLIENTS_WITH_MFA = ['REPLACE_WITH_{yourClientId}'];
 // 指定されたクライアントのみ実行する
 if (CLIENTS_WITH_MFA.includes(event.client.client_id)) {
 // ウェブアプリが認証リクエストでMFAを要求した場合のみMFAを求める
 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 変数には、この Action を適用するアプリケーションの が含まれます。不要であれば、これ (および後続の 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() メソッドの詳細については、Action Triggers: post-login API object を参照してください。
  • http://schemas.openid.net/pape/policies/2007/06/multi-factor ポリシーは、エンドユーザーが複数の認証要素、つまり MFA を提示して Provider に認証する認証メカニズムを定義します。詳細については、OpenID Provider Authentication Policy Extension 1.0 を参照してください。

​
アプリを設定する

ユーザーが制限された給与情報ページにアクセスしようとした際に、MFA を使用して認証済みであることを確認するようアプリを設定します。 (ユーザーが MFA で認証されている場合、IDトークンの クレーム には、値が mfa の amr クレーム が含まれます。) ユーザーがすでに MFA で認証されている場合、Web アプリは制限されたページを表示します。そうでない場合、Web アプリは acr_values パラメーターに次の値を含む新しい認証リクエストを送信します。 http://schemas.openid.net/pape/policies/2007/06/multi-factorこれにより Action がトリガーされます。 このシナリオの Web アプリは認証に Authorization Code Flow を使用するため、リクエストは次のとおりです。 ユーザーがMFAで認証されると、Webアプリは認可コードを受け取ります。この認可コードは新しいIDトークンと交換する必要があり、そのIDトークンには mfa を値とする amr クレームが含まれているはずです。認可コードをIDトークンと交換する方法については、Authorization Code Flow を使用したログインの追加 を参照してください。

​
IDトークンを検証する

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

​
詳細はこちら