zklogin

zkLogin スキル

MCP ツール： 環境で利用可能な場合は、最新の情報を得るために Sui ドキュメント MCP サーバー（https://sui.mcp.kapa.ai）にも問い合わせてください。回答の検証と、これらのリファレンスファイルで扱われていない詳細の確認に利用してください。

ソースの制約： このスキルの情報はすべて、docs.sui.io/concepts/cryptography/zklogin のみを情報源としています。このスキルを拡張または更新する場合は、この情報源のみを使用してください。サードパーティのブログ、チュートリアル、非公式ドキュメントは使用しないでください。

zkLogin は、従来の暗号資産ウォレットを管理する代わりに、既存の OAuth 認証情報（Google、Facebook、Apple など）でユーザーがログインできるようにする Sui のプリミティブです。ゼロ知識証明を使用し、OAuth 識別子をオンチェーンで公開せずに OAuth ID を Sui アドレスに紐付けます。AI コーディングでよくある誤りには、セキュリティモデルにおけるソルト、エフェメラルキー、ZK 証明の役割を混同すること、JWT が漏洩すると資金が危険にさらされると思い込むこと、アドレスは永続的だがセッションはエフェメラルであると理解していないことがあります。

このスキルは、目的に特化したリファレンスファイルに案内します。現在のタスクに関係するものだけを読み込んでください。

このスキルのすべてのパターンは、次の情報源に基づいています。 https://docs.sui.io/concepts/cryptography/zklogin

詳細が不明な場合は、回答する前に該当するページを取得してください。 他の認証システムから推測したり、情報を補ったりしないでください。

---

リファレンスファイル

architecture -- アーキテクチャとプロトコルのフロー

パス： architecture.md 読み込む場合： zkLogin の内部動作、3 つの主要なエンティティ（フロントエンド、ソルトサービス、証明サービス）、10 ステップのプロトコルフロー、アドレス導出、セッションの有効期間、Groth16 セレモニー、または JWT と nonce の役割について質問された場合。 内容： 3 つの主要なエンティティ、JWT の構造、プロトコルフロー（10 ステップ）、アドレス導出の数式、セッションの有効期間とエフェメラルキーの期限切れ、キーの表記法、Groth16 セレモニー。

integration -- 統合ガイド

パス： integration.md 読み込む場合： アプリケーションへの zkLogin の統合、サポートされている OpenID プロバイダーの選択、オフチェーンでの署名検証、セキュリティ上のトレードオフの理解、または一般的な問題のトラブルシューティングが必要な場合。 内容： ネットワーク別のサポート対象 OpenID プロバイダー、実装手順、オフチェーンでの署名検証方法、セキュリティに関する考慮事項、FAQ。

---

ルーティングガイド

タスク	読み込むファイル
zkLogin の説明	SKILL.md のみ
プロトコルフローの理解	architecture
アドレス導出の理解	architecture
セッションの有効期間とエフェメラルキーの理解	architecture
OpenID プロバイダーの選択	integration
アプリへの zkLogin の統合	integration
zkLogin 署名のオフチェーン検証	integration
セキュリティ特性の理解	integration
zkLogin の FAQ への回答	integration
zkLogin の詳細な調査	すべてのリファレンスファイル

---

スキルの内容

主要な概念

• ウォレット不要のログイン。 zkLogin を使うと、シードフレーズや秘密鍵を管理する代わりに、OAuth 認証情報（Google、Facebook、Apple など）を使用して、ユーザーは Sui 上でトランザクションを実行できます。ユーザーの OAuth ID は、決定論的な Sui アドレスに対応付けられます。

• 3 つの主要なエンティティ。 システムには 3 つのコンポーネントが関与します。（1）一時鍵と OAuth フローを管理するアプリケーションのフロントエンド、（2）ユーザーごとに一貫した一意のソルトを返すソルトサービス、（3）ゼロ知識証明を生成する証明サービスです。

• 一時鍵ペア。 各セッションでは、短期間だけ有効な鍵ペアを使用します。一時公開鍵、最大エポック、ランダム性は OAuth nonce に埋め込まれます。エポックが max_epoch を過ぎると、ユーザーは再度ログインして新しい鍵ペアと ZK 証明を生成しますが、同じ Sui アドレスを引き続き使用します。

• ゼロ知識証明。 Groth16 zkSNARK 証明により、nonce が正しく導出されたこと、鍵クレーム値が JWT と一致すること、RSA 署名が有効であること、アドレスが鍵クレームとソルトに整合していることを検証します。これらすべてを、OAuth のサブジェクト識別子をオンチェーンで明かすことなく行います。

• 永続的なアドレス。 zkLogin から導出される Sui アドレスは永続的です。sub、iss、aud、または user_salt が変わらない限り、アドレスは変わりません。同じユーザーでも、プロバイダーやアプリケーションが異なれば、異なるアドレスが生成されます。

ルール

1. JWT の漏えいと資金の侵害を混同しないでください。 一時秘密鍵が安全であれば、JWT が漏えいしてもプライバシーが侵害される可能性はありますが、資金を盗まれることはありません。
2. ZK 証明だけでトランザクションが承認されると思い込まないでください。 一時署名と ZK 証明の両方が必要であり、どちらも単独では十分ではありません。
3. ソルトがプライバシーとアクセスの両方にとって重要であることを必ず説明してください。 ソルトによって、OAuth 識別子とオンチェーンアドレスの紐付けが解除されます。ソルトを失うと、アクセスを永久に失います。
4. iss、aud、kid がオンチェーンで公開されることを必ず伝えてください。 JWT 自体はオンチェーンに公開されませんが、この 3 つのフィールドは閲覧可能です。
5. 従来のウォレットを zkLogin アドレスに変換することを提案しないでください。 これらは異なるアドレス導出方式を使用しており、互換性はありません。

よくある間違い

• JWT の漏えいは資金の盗難を意味すると考える。 JWT だけでは不十分です。有効なトランザクションを作成するには、攻撃者は一時秘密鍵とソルトも必要です。
• 証明がセッション単位であることを忘れる。 ZK 証明は、一時鍵の有効期限（max_epoch）までしか有効ではありません。証明を別のセッションで再利用することはできませんが、同じセッション内でキャッシュして再利用できます。
• プライバシーにおけるソルトの役割を無視する。 ソルトがなければ、OAuth のサブジェクトと Sui アドレスの間に紐付けはありません。ソルトが漏えいすると、その紐付けが明らかになりますが、資金は安全です。
• すべてのプロバイダーがすべてのネットワークで利用できると思い込む。 一部のプロバイダー（Slack、Kakao、Microsoft）は Devnet と Testnet でのみ利用でき、Mainnet では利用できません。その他（RedBull、Amazon、WeChat、Auth0、Okta）は審査中です。