Skip to main content
Highly Regulated Identity の機能を利用するには、Highly Regulated Identity アドオンが含まれる Enterprise Plan が必要です。詳しくは、Auth0 Pricing を参照してください。
Highly Regulated Identity (HRI) は、ビジネス上重要な機密データの処理やサービスを保護するための、Auth0 の Financial-Grade Identity™ ソリューションです。主に金融や医療など、厳格な規制を受ける業界向けに設計されており、送金、デジタル決済、医療記録へのアクセスをはじめとする幅広いユースケースに対して、より高度なセキュリティを提供します。また、管理者認証情報の変更承認や Web ポータルへの特権アクセスの保護など、強化されたセキュリティが求められるその他の機密性の高い操作にも利用できます。 機密性の高いビジネス上の操作を保護するために、Highly Regulated Identity は次の機能を提供します。

​
OpenID Connect (FAPI) による高度なセキュリティ

OpenID FAPI は、 Foundation が策定した、セキュリティおよびプライバシーに関する一連の仕様です。FAPI 標準を満たす API は「financial-grade」に分類され、金融データやその他の機微なデータ、サービスへのアクセスを保護するための、堅牢な認証・認可の仕組みを提供します。 Auth0 は認定 FAPI プロバイダーです。FAPI 標準に準拠するために Auth0 が導入したセキュリティ強化について詳しくは、以下のセクションを参照してください。 FAPI の詳細については、OpenID のホワイトペーパー Open Banking, Open Data, and Financial-grade APIs と FAPI Working Group specifications を参照してください。

​
強固な顧客認証 (SCA)

欧州の決済サービス指令 (PSD2) で導入された強固な顧客認証 (SCA) では、次の3つのうち少なくとも2つの異なる認証要素を使用することが義務付けられています。
  • ユーザーが知っているもの (例: パスワード)
  • ユーザーが所持しているもの (例: デバイス)
  • ユーザー自身に備わっているもの (例: 指紋)
認証要素は相互に独立している必要があり、1つが侵害されても他の要素に影響が及ばないようにしなければなりません。SCAは、機密データやサービスを保護するための世界標準として急速に広がっています。 SCA準拠を支援するため、Auth0 は、ログイン処理中にユーザーの登録と認証を行うさまざまな認証要素を提供しています。Highly Regulated Identity では、トランザクションを保護するために次の認証要素を活用します。
  • モバイルプッシュ通知
  • SMS
  • メール
  • WebAuthn
Actionsを使用すると、使用する認証要素を動的に判断できます。これにより、コードロジックを柔軟にカスタマイズできます。たとえば、10米ドルを超える支払いに対して第2の認証要素を追加できます。詳しくは、動的ポリシーの適用をご覧ください。

​
動的リンク

PSD2では、決済サービスプロバイダーに対し、強固な顧客認証とあわせて動的リンクを実装することが求められています。動的リンクでは、ユーザーが明示的に確認して承認できるように取引の詳細を提示し、認可と取引の詳細を一意に関連付けます。これにより、優れたユーザー体験を実現するとともに、規制遵守にも役立ちます。 動的リンクを有効にするには、Rich Authorization Requests (RAR) を使用して、詳細な取引認可データを認可エンドポイントに渡すことができます。次のコード例は、authorization_details JSONオブジェクトを示しています。このオブジェクトには、支払いの種類、金額、通貨、受取人などの情報が含まれています。
authorization_details には一意のトランザクション参照が割り当てられ、Auth0 はこれを使用して、ユーザーにステップアップ認証を求めます。
  • プッシュ通知を使用してトランザクションの詳細を表示し、モバイルアプリなどの別のデバイスで承認を得ます。
  • SMS、メール、または WebAuthn を使用して、ユーザーが第 2 要素の認証を完了した後、トランザクションの発生元のデバイス上で詳細を確認します。
authorization_details の外に、詳細なトランザクション認可データやその他の機密データ、または規制対象データを渡さないでください。
ユーザーが詳細を確認すると、トランザクションは続行され、Auth0 は承認済みの authorization_details に関連付けられた を発行します。開発者は、この一意のトランザクション参照をアクセストークンに追加することもできます。これにより、API サーバーは後で API リクエストを受信して処理する際に、承認されたトランザクションの詳細を検証できます。 RAR について詳しくは、Authorization Code Flow with Rich Authorization Requests を参照してください。

​
機密性と完全性の保護

認可の詳細には、口座番号、金額、加盟店名など、非常に機微性の高い情報が含まれることがあり、こうした情報が安全でない URL やアクセストークンを介して受け渡される場合があります。Highly Regulated Identity は、機微なデータを不正アクセスや改ざんから保護するために、包括的な機密性および完全性の保護を提供します。

​
フロントチャネルで機密データを保護する

Web ブラウザーなどのフロントチャネルで機密データを保護するため、Highly Regulated Identity では、FAPI 1 Advanced Security プロファイルの一部として、以下のソリューションを提供しています。

​
Pushed Authorization Requests (PAR)

PAR では新しいエンドポイントが導入され、クライアントは OAuth 2.0 認可リクエストのペイロードを (この場合は Auth0) に直接送信できるようになります。これにより、安全ではないフロントチャネル (つまりブラウザー) 経由で認可パラメーターを渡す必要がなくなり、仲介者によって認可パラメーターに不正アクセスされるリスクを低減できます。 PAR の詳細については、Authorization Code Flow with Pushed Authorization Requests (PAR) および Configure Pushed Authorization Requests (PAR) を参照してください。

​
JWT で保護された認可リクエスト (JAR)

JAR は、認可リクエストのセキュリティを強化する OAuth2 のプロトコル拡張です。認可リクエストのパラメーターの完全性と、必要に応じて機密性を保護するために、 (JWT) のリクエストパラメーターを使用します。 JAR について詳しくは、JWT で保護された認可リクエスト (JAR) を使用する Authorization Code Flow および JWT で保護された認可リクエスト (JAR) の設定 をご覧ください。

​
アクセストークン内の機密データを保護する

アクセストークンに含まれる認可の詳細を保護するため、Highly Regulated Identity では JSON Web Encryption (JWE) を使用してアクセストークンのペイロードを暗号化できます。これにより、アプリケーション側でのデータ侵害や、中継者による API 呼び出しの不正な検査からアクセストークンを保護できます。 JWE の詳細については、JSON Web Encryption および Configure JSON Web Encryption を参照してください。

​
より強固なアプリケーション認証

アプリケーション認証のセキュリティを強化するために、Highly Regulated Identity では、FAPI 1 Advanced Security プロファイルの一部として、2 つの選択肢を提供しています。
  • Private Key JWT: アプリケーションの認証に使用する認証情報として、公開鍵と秘密鍵の鍵ペアを生成する方式です。これは Enterprise プランのお客様にはすでに提供されています。詳しくは、Private Key JWT Authentication をご覧ください。
  • mTLS for OAuth: テナント上のアプリケーションに関連付けられた標準の X.509 証明書を登録する方式です。証明書は、CA 発行のものでも自己署名のものでも使用できます。標準的な mTLS の手順に従い、証明書に対応する秘密鍵をクライアント側で使用して、Auth0 テナントのエンドポイントにリクエストを送信する際に mTLS トンネルを確立します。その結果、Auth0 はネットワーク経由でシークレットを送信することなく、アプリケーションを認証できます。詳しくは、mTLS for OAuth をご覧ください。
Private Key JWT と OAuth 2.0 mTLS はどちらも、特定のアプリケーションに対して 2 つの有効な鍵や証明書を一時的に同時保持できるため、ダウンタイムなしで認証情報をローテーションできます。

​
Token Binding でアクセストークンを保護する

mTLS をサポートすると、Token Binding または Sender Constraining も利用できるようになります。Token Binding は、mTLS トンネルの確立に使用されたクライアント証明書のサムプリントをアクセストークンに関連付ける仕組みです。クライアントがその証明書にバインドされたアクセストークンを使って API を利用すると、API サーバーは、クライアントが対応するクライアント証明書も使用しているかどうかを検証できます。そのため、たとえアクセストークンが漏えいしても、クライアント証明書を持たない悪意のある第三者は保護されたリソースにアクセスできません。 注: Token Binding はアプリケーションの認証方式とは独立して機能し、クライアント証明書を事前登録する必要もありません。詳しくは、Configure Sender Constraining をご覧ください。

​
より優れたユーザー体験を実現するカスタマイズ可能な承認フロー

金融グレードのセキュリティに対応した実運用向けソリューションを設計する際は、ユーザー体験を考慮することが重要です。すべてのトランザクションに画一的な認証フローを適用するよりも、トランザクションの詳細やユースケースに応じて動的に調整するほうが効果的です。 Actions を使用して認証フローをカスタマイズできます。たとえば、ユーザーのログイン後に、RAR 経由で受け取ったトランザクションの詳細を確認し、ユーザーが登録済みかつ検証済みの認証要素を一覧化したうえで、リスク評価エンジンなどの外部サービスを利用して、次に使用する認証要素を決定できます。詳しくは、動的ポリシーを適用する をご覧ください。 新しい テンプレートでは、トランザクションの種類やその他の認可の詳細に応じて、トランザクション承認画面に表示する属性をカスタマイズすることもできます。詳しくは、Rich Authorization Requests (RAR) を設定する をご覧ください。

​
詳しく見る

Highly Regulated Identity がエンドツーエンドでどのように機能し、1 回限りの取引を認可するのかについては、Authorization Code Flow を使用したトランザクション認可 をお読みください。