Skip to main content
ステップアップ認証では、さまざまな種類のリソースへのアクセスを許可するアプリケーションで、機密情報へのアクセスや特定のトランザクションの実行時に、より強固な認証方式をユーザーに要求できます。 たとえば、ユーザーは (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. 次のクレームを検証します。

AMRクレームの例外

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

例: MFAありの場合の値

例: MFAなしの値

シナリオ: プッシュ通知による給与データへのアクセス

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

前提条件

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

Action を作成する

ウェブアプリから要求されたときに、ユーザーに MFA での認証を求める Action を作成します。Auth0 Dashboard > Actions > Flows に移動し、次の内容を含む Action を作成します。
  • CLIENTS_WITH_MFA 変数には、この Action を適用するアプリケーションのが含まれます。不要であれば、これ (および後続の if 条件) を削除できます。
  • event.transaction.acr_values プロパティは、認証コンテキストクラス参照 (acr) を含む文字列の配列です。これは省略可能なプロパティで、アプリケーションが への認証リクエストにこれを含めた場合にのみ存在します。この例では、Web アプリは、まだ MFA で認証していないユーザーが給与情報にアクセスしようとした場合にのみ、これを認証リクエストに含めます。Web アプリがこれを含める場合、http://schemas.openid.net/pape/policies/2007/06/multi-factor という値を設定します。これは、Authorization Server に 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 トークンのクレームには、値が mfaamr クレームが含まれます。) ユーザーがすでに MFA で認証されていれば、ウェブアプリは制限されたページを表示します。そうでない場合、ウェブアプリは、値が http://schemas.openid.net/pape/policies/2007/06/multi-factoracr_values パラメータを含む新しい認証リクエストを送信し、これによって Action がトリガーされます。 このシナリオのウェブアプリは認証に Authorization Code Flow を使用するため、リクエストは次のとおりです。 ユーザーがMFAで認証されると、WebアプリはAuthorization Codeを受け取ります。これを新しいIDトークンと交換する必要があります。新しいIDトークンには、mfa を値に持つ amr クレーム が含まれているはずです。コードをIDトークンに交換する方法については、Authorization Code Flow を使用してログインを追加する を参照してください。

ID トークンを検証する

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

詳しくはこちら