メインコンテンツへスキップ
Highly Regulated Identity の機能を使用するには、Highly Regulated Identity アドオンを含む Enterprise Plan が必要です。詳しくは、Auth0 Pricingを参照してください。
Highly Regulated Identity (HRI) は、機密性の高いデータ処理や、ビジネス上重要なサービスを保護するための Auth0 の Financial-Grade Identity™ ソリューションです。主に金融や医療などの厳格な規制対象業界を想定しており、送金、デジタル決済、医療記録へのアクセスなどを含む幅広いユースケースを保護できるよう、セキュリティレベルを引き上げます。また、管理者認証情報の変更承認や Web ポータルへの特権アクセスの保護など、強化されたセキュリティが求められるその他の機密性の高い操作にも Highly Regulated Identity を使用できます。 機密性の高いビジネス上の操作を保護するために、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 USD を超える支払いに対して第 2 の認証要素を追加できます。詳しくは、動的ポリシーを適用するを参照してください。

​
動的リンク

PSD2では、決済サービスプロバイダーは Strong Customer Authentication (SCA) とあわせて動的リンクを実装する必要があります。動的リンクでは、ユーザーにトランザクションの詳細を提示して明示的な確認と承認を求めるとともに、認可とトランザクションの詳細を一意に結び付けます。これにより、良好なユーザー体験を実現でき、規制遵守にも役立ちます。 動的リンクを有効にするには、Rich Authorization Requests (RAR) を使用して、きめ細かいトランザクション認可データを認可エンドポイントに渡すことができます。次のコードサンプルは、支払いの種類、金額、通貨、受取人などの情報を含むauthorization_details JSONオブジェクトを示しています。 
"authorization_details": [
 {
   "type": "one_time_payment",
   "amount": {
     "amount": 2460.46,
     "currency": "USD"
   },
   "sourceAccount": "xxxxxxxxxxx4567",
   "recipient": "Acme Travel, Inc.",
   "concept": "All Inclusive Resort Package for Two",
 }
]
authorization_details には一意のトランザクション参照が割り当てられ、Auth0 はこれを使用してユーザーに追加認証を行うよう促します。
  • プッシュ通知を使用してトランザクションの詳細を表示し、モバイルアプリなどの別のデバイスで承認を取得します。
  • ユーザーが 2 つ目の認証要素を完了した後、SMS、メール、または WebAuthn を使用して、トランザクションを開始したデバイス上で詳細を確認します。
詳細なトランザクション認可データや、その他の機密データまたは規制対象データを 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 プロファイルの一部として次のソリューションを提供しています。

​
プッシュド認可リクエスト (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 または送信者制約も利用できるようになります。Token Binding は、mTLS トンネルの確立に使用されたクライアント証明書のサムプリントをアクセストークンに関連付けます。クライアントが証明書にバインドされたアクセストークンを使用して API を利用する際、API サーバーは、クライアントが対応するクライアント証明書も使用しているかどうかを検証できます。その結果、アクセストークンが侵害された場合でも、クライアント証明書を持たない悪意のある第三者は保護されたリソースにアクセスできません。 注: Token Binding はアプリケーションの認証方式とは独立して動作し、クライアント証明書を事前登録する必要もありません。詳しくは、送信者制約を構成する を参照してください。

​
ユーザーエクスペリエンスを向上させるカスタマイズ可能な承認フロー

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

​
詳細情報

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