ハイリーレギュレーテッドアイデンティティ

ハイリーレギュレーテッドアイデンティティ（HRI）は、Auth0のFinancial-Grade Identity™ソリューションであり、ビジネスにとって重要な機密データの操作やサービスをセキュリティ保護します。ハイリーレギュレーテッドアイデンティティは、金融や医療など高度に規制された業界を対象としており、送金、デジタル決済、医療記録へのアクセスなどを含みますがこれらに限らず、幅広い顧客のユースケースを保護するためにセキュリティレベルを強化します。また、ハイリーレギュレーテッドアイデンティティを使用すると、管理者の資格情報の変更承認や、特権アクセスを持つWebポータルのセキュリティ保護など、その他の機密操作にも強化されたセキュリティを提供します。

ハイリーレギュレーテッドアイデンティティは、機密性の高い業務運用を保護するために以下を提供します。

• OpenID Connectを使用した高度なセキュリティ（FAPI）

• 強力な顧客認証（SCA）と動的リンキング

• 機密性と完全性の保護

• 強力なアプリケーション認証

• トークンバインディングを使用したアクセストークンの保護

• より良いユーザーエクスペリエンスのためのカスタマイズ可能な承認フロー

OpenID FAPIは、OpenID Foundationによって開発されたセキュリティおよびプライバシーの仕様群です。FAPI基準を満たすAPIは「金融グレード」と分類され、強力な認証と認可メカニズムを提供し、金融およびその他の機密データやサービスへのアクセスをセキュリティ保護します。

Auth0は証明書付きのFAPIプロバイダーです。FAPI基準を満たすセキュリティの向上については、以下のセクションを参照してください。

• 機密性と完全性の保護

• 強力なアプリケーション認証

• トークンバインディングを使用したアクセストークンの保護

FAPIについての詳細は、OpenIDのホワイトペーパー『Open Banking, Open Data, and Financial-grade APIs(オープンバンキング、オープンデータ、および金融グレードAPI)』とFAPI作業部会の仕様を参照してください。

欧州の決済サービス指令（PSD2）によって導入された強力な顧客認証（SCA）では、次の3つのうち少なくとも2つの異なる認証要素を使用することが義務付けられています。

• ユーザーが知っている情報（例：パスワード）

• ユーザーが持っているもの（例：デバイス）

• ユーザー自身に内在するもの（例：指紋）

一つが侵害されても他の要素が危険にさらされないように、認証要素は独立している必要があります。SCAは、機密データやサービスを保護するための世界的な標準として急速に普及しています。

Auth0は、SCAへの準拠を支援するために、ログイントランザクション中にユーザーを登録し、チャレンジするさまざまな認証要素を提供しています。ハイリーレギュレーテッドアイデンティティは、トランザクションをセキュリティ保護するために次の認証要素を利用します。

• モバイル・プッシュ通知

• SMS

• メール

• WebAuthn

Actionsを使用することで、どの認証要素を使用するか動的に決定できます。これにより、コードロジックをカスタマイズする柔軟性が得られます。例えば、10米ドルを超える決済に対する第二認証要素を追加できます。詳しくは、「動的ポリシーの適用」をお読みください。

PSD2は、決済サービスプロバイダーに対して、強力な顧客認証とともに動的リンキングを実装するように要求します。動的リンキングでは、ユーザーにトランザクションの詳細を提示して明示的な検証と承認を求め、認可とトランザクションの詳細を一意にリンクします。これにより、ユーザーエクスペリエンスが向上し、規制遵守にも役立ちます。

動的リンキングを有効にするには、リッチ認可要求（RAR）を使用して、OAuth認可エンドポイントに詳細なトランザクション認可データを渡すことができます。以下のコードサンプルは、authorization_detailsJSONオブジェクトを示しており、決済タイプ、金額、通貨、受信者などの情報を含みます。

"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はこれを使用してユーザーにステップアップ認証を実行します。

• プッシュ通知を使用して、トランザクションの詳細を表示し、モバイルアプリケーションなど別のデバイスで承認を得ます。

• ユーザーが第二認証要素を完了したあとに、SMS、メール、WebAuthを使用して、トランザクションを開始したデバイスで詳細を確認します。

ユーザーが詳細を確認したら、トランザクションが進行し、Auth0は承認されたauthorization_detailsに関連付けられたアクセストークンを発行します。また、開発者は、アクセストークンに一意のトランザクション参照を追加することもできます。その結果、APIサーバーはAPI要求を受け取り、サービスを提供する際に承認されたトランザクションの詳細を後で検証できます。

RARの詳細については、「リッチ認可要求（RAR）を使用した認可コードフロー」をお読みください。

認可の詳細には、口座番号、金額、販売者名、その他の機密性の高い情報が含まれる場合があり、これらは保護されていないURLやアクセストークンで渡されます。未認可のアクセスや改ざんから機密データを保護するために、ハイリーレギュレーテッドアイデンティティは機密性と完全性の包括的な保護を提供します。

機密データをWebブラウザーなどのフロントチャネルで保護するために、ハイリーレギュレーテッドアイデンティティはFAPI 1高度なセキュリティプロファイルの一部として以下のソリューションを提供します。

PARは新しいエンドポイントを導入しており、クライアントがOAuth 2.0認可要求のペイロードを直接認可サーバー（この場合はAuth0）にプッシュできるようにします。これにより、認可パラメーターを安全でないフロントチャネル（つまりブラウザ）を介して渡すことが避けられ、中間者による認可パラメーターへの不正アクセスのリスクが減少します。

PARの詳細については、「プッシュ認可要求（PAR）を使用した認可コードフロー」と「プッシュ認可要求（PAR）を構成する」をお読みください。

JARは、OAuth2プロトコル拡張機能で、認可要求のセキュリティを向上させます。これにより、JSON Webトークン（JWT）要求パラメーターを使用して、認可要求パラメーターの完全性と、オプションで機密性も保護します。

JARの詳細については、「JWT保護の認可要求（JAR）を使用した認可コードフロー」と「JWT保護の認可要求（JAR）を構成する」をお読みください。

アクセストークンに含まれる認可の詳細を保護するために、ハイリーレギュレーテッドアイデンティティは、JSON Web暗号化（JWE）を使用してアクセストークンのペイロードを暗号化するサポートを提供します。これにより、アプリケーション側でのデータ侵害や、仲介者によるAPI呼び出しの不正な検査からアクセストークンを保護します。

JWEの詳細については、「JSON Web暗号化」と「JSON Web暗号化の構成」をお読みください。

アプリケーション認証のセキュリティを向上させるために、ハイリーレギュレーテッドアイデンティティはFAPI 1高度なセキュリティプロファイルの一部として2つの異なる代替案を提供します。

• 秘密鍵JWT：アプリケーションを認証するために、公開鍵と秘密鍵のペアを生成し、これを認証の資格情報として使用することを伴います。秘密鍵JWTは、エンタープライズプランの顧客のみ使用することができます。詳細については、「秘密鍵JWTの認証」をお読みください。

• OAuthのmTLS：テナントのアプリケーションにリンクされた標準のX.509証明書の登録を伴います。証明書は、CA発行または自己署名のいずれかになります。標準的なmTLS手順に従い、証明書に対応する秘密鍵はクライアント側で使用され、Auth0テナントのエンドポイントに要求を送信する際にmTLSトンネルを確立します。その結果、Auth0はネットワーク上でシークレットを送信することなくアプリケーションを認証できます。詳細については、「OAuthのmTLS」をお読みください。

秘密鍵JWTとOAuth0 2.0 mTLSの両方を使用することで、指定されたアプリケーションに同時に2つのアクティブなキーや証明書を一時的に保持することで、ダウンタイムなしで資格情報をローテーションできます。

mTLSをサポートすることで、トークンバインディングまたは送信者制約の使用が可能になります。トークンバインディングは、mTLSトンネルの確立に使用されたクライアント証明書のサムプリントをアクセストークンに関連付けます。クライアントが証明書にバインドされたアクセストークンを使用してAPIを利用する際、APIサーバーはクライアントが関連付けられたクライアント証明書も使用しているかどうかを検証できます。その結果、アクセストークンが漏洩しても、クライアント証明書を知らない悪意のある第三者は保護されたリソースにアクセスできません。

注意：トークンバインディングはアプリケーションの認証方法とは独立して動作し、クライアント証明書の事前登録を必要としません。詳細については、「送信者制約を構成する」をお読みください。

金融グレードのセキュリティを備えた現実的なソリューションを設計する際には、ユーザーエクスペリエンスを考慮することが重要です。すべての取引に一律の認証フローを適用するよりも、取引の詳細やユースケースに基づいて動的に調整する方が効果的です。

Actionsを使用して、認証フローをカスタマイズできます。例えば、ユーザーがログインした後、RARを介して受け取った取引詳細を確認し、ユーザーの登録済みかつ検証済みの認証要素を一覧し、リスク評価エンジンなどの外部サービスを利用して、次に使用する認証要素を決定することができます。詳細については、「動的ポリシーの適用」をお読みください。

New Universal Loginのテンプレートでは、取引の種類やその他の認証詳細に応じて、取引承認画面に表示される属性をカスタマイズすることもできます。詳細については、「詳細な認可要求（RAR）を構成する」をお読みください。

ハイリーレギュレーテッドアイデンティティがワンタイム取引を認可するためにどのようにエンドツーエンドで機能するかについては、「コンテキストに基づいた強力な顧客認証を使用した取引認可」をお読みください。