> ## Documentation Index > Fetch the complete documentation index at: https://docs.iru.com/llms.txt > Use this file to discover all available pages before exploring further. # 認証アーキテクチャ > Iru がサインインをフィッシング耐性のあるものにし、すべてのリクエストに署名してリプレイを防止し、ローテーションするキーで検証可能な SSO の信頼を確立する方法。認証は、Iru の中で最もだまされにくくなければならない部分です。以下では、暗号の基盤について説明します。ユーザーが共有可能な秘密情報なしで本人であることを証明する方法、リクエストに署名してリプレイを防止する方法、および Iru がアプリに提供する信頼が検証可能で安全にローテーションされる方法です。 ## フィッシング耐性のあるサインイン Iru は**パスキー (WebAuthn/FIDO2)** とデバイスにバインドされた資格情報を中心に構築されています。フィッシング、再利用、漏洩の対象となるパスワードはありません。パスキーは、暗号的に Iru の正確なオリジンにスコープされています。Iru 用に発行された資格情報は、類似したフィッシングドメインでは有効な署名を生成しません。 Iru は、**公開**鍵、認証器の出所 (AAGUID)、および署名カウンターのみを保存します。秘密鍵はユーザーのデバイスから出ることがないため、サーバー上に盗まれるものはありません。サインインには検出可能な (常駐) 資格情報が必要で、登録時に認証器の構成証明を取得するため、Iru は使用中の認証器の種類を把握できます。 Iru Access アプリは、デバイスのセキュアなハードウェア (Apple では **Secure Enclave**、Windows では **TPM**) にキーを保持し、資格情報ごとの署名ですべてのリクエストで所有を証明します。 Secure Enclave / TPM によるキーの保管は、デバイス上の Iru Access アプリの特性です。サーバーは各呼び出しで、デバイスにバインドされた公開鍵の署名を検証します。 ## デバイスが本物であることの証明 *誰が*サインインしているかを証明するだけでなく、Iru は*何を*使用しているかを検証できます。Apple の **DeviceCheck** は、リクエストが本物の改ざんされていない Apple デバイスから送信されたことを検証し、このチェックは**フェイルクローズ**です。これを回避するには意図的な構成が必要です。Windows では、Iru Access によって報告される TPM シグナルがデバイストラストの態勢の決定に使用されます。[Device trust](/ja/identity/authentication/device-trust) を参照してください。 ## すべてのリクエストは署名され、リプレイが防止される Iru Access アプリと統合からのリクエストは、ベアラートークンで認証されるだけではありません。**署名**され、キャプチャされたリクエストを再利用できないようにバインドされています。 | メカニズム | 標準 | 機能 | | - | - | - | | **HTTP Message Signatures** | RFC 9421 | メソッド、パス、オーソリティ、および主要なリクエストコンポーネントに署名するため、転送中に改ざんされるとリクエストが無効になります。スキーム: `ed25519`、`ecdsa-p256-sha256`、`rsa-v1_5-sha256`。 | | **Content-Digest** | RFC 9530 | SHA-256/512 ダイジェストにより、署名が正確なリクエスト本文にバインドされます。 | | **使い捨ての期限付き証明** | - | 署名には `created`/`expires` ウィンドウ (最大約 10 分、クロックスキュー 5 秒以下) と、**一意性制約付きで保存されるナンス**が含まれます。リプレイされたナンスは拒否されます。 | | **DPoP** | RFC 9449 | クライアントが保持するキーにバインドされた、送信者制約付きの所有証明トークン (`htm`/`htu`/`ath` バインディングと証明ごとの JTI を使用)。盗まれたベアラートークンは秘密鍵がなければ役に立ちません。 | Iru Access アプリはさらに、通信するサービスの TLS 証明書をピン留めするため (エージェント側のコントロール)、傍受するプロキシを信頼しません。 ## 安全なキーローテーションを伴う検証可能な SSO の信頼 Iru が ID プロバイダーとして機能する場合、アプリに送信するステートメントは**署名**されているため、各アプリはそれが本当に Iru から送信され、改ざんされていないことを検証できます。 SAML レスポンスとアサーションは XML Signature で署名されます。アサーションはさらにサービスプロバイダー向けに**暗号化**することもできます。OIDC ID トークンは JWS 署名されます。Iru は最新のアルゴリズム (SHA-256 以上の RSA/ECDSA、AES-GCM コンテンツ暗号化、RSA-OAEP キーラッピング) をサポートしており、各サービスの要件に合わせて統合ごとに選択できます。 Iru は公開鍵とメタデータを標準のエンドポイントで公開しています: **JWKS** ドキュメント、OAuth Authorization Server Metadata (RFC 8414)、および OpenID Connect Discovery。証明書利用者はキーを自動的に構成および更新します。署名キーは **30 日**のスケジュールで **24 時間の重複**を伴ってローテーションされます。新しいキーが引き継ぐ間、以前のキーは処理中のトークンの検証を続け、その後削除されるのではなく期限切れになります。キーの種類には ECDSA P-256/384/521 と RSA-2048 が含まれます。これにより、アプリを中断することなく、単一のキーの影響範囲が制限されます。 ## 暗号化とセッション * **転送中:** すべてのトラフィックは TLS で保護されます。セッション Cookie は `Secure`、`HttpOnly`、`SameSite` です。 * **保存時:** 機密フィールドは、マネージドシークレットストアから実行時に提供されるキーを使用して **AES-256-GCM** で暗号化されます。 * **セッション:** サインインセッションは短命で、スライディング方式の非アクティブウィンドウがあります。より長期間のフローでは、ワンタイムコードチャレンジ (PKCE `S256`) とリプレイ検出を伴うローテーションするリフレッシュトークンを使用します。セッションは**グローバル、ユーザーごと、または認証器ごと**に取り消すことができるため、紛失したデバイスや侵害されたアカウントを即座に遮断できます。[資格情報とセッション](/ja/identity/security/credentials-and-sessions)を参照してください。 ## 次のステップその背後にあるサービス、リージョン、インフラストラクチャ。各テナントのデータが分離され、監査可能な状態に保たれる仕組み。ユーザーが日常的に使用するパスキーと Iru Access アプリ。特定のアプリが受け取る署名と暗号化を構成します。