web3認証ガイド

Web3認証は、従来のメールアドレスやパスワードではなく、公開鍵を通じてユーザーを検証します。この暗号技術的アプローチは、中央集権的なパスワードデータベースを排除し、ユーザーにデジタル認証情報の真の所有権を与える一方で、シードフレーズ、16進数アドレス、鍵管理の複雑さがメインストリームでの採用に大きな障壁を作り出してきました。埋め込みウォレット、アカウント抽象化、スマートコントラクトアカウントにおける最近の技術革新が、これらの課題を解決しつつあります。

このガイドでは、web3認証がどのように機能するかを説明し、よりアクセスしやすくするための技術的なソリューションを探り、最新のスマートウォレットインフラを使って本番環境に対応した認証を実装する方法を示します。

Web3認証はどのように機能するのか?

従来のウェブ認証は、中央集権的なサーバーに保存された認証情報に依存しています。ユーザー名とパスワードを入力すると、サーバーがデータベースを照合し、一致すればアクセスを許可します。このモデルでは、ユーザーはサービスプロバイダーに認証データを信頼して預ける必要があります。

Web3認証はこのモデルを逆転させます。ユーザーはweb3ウォレットをアプリケーションに接続することで認証を行い、通常はトランザクションに署名することで行われます。技術的な流れは次のとおりです。

1. ウォレット接続

ユーザーが「Connect Wallet」をクリックすると、アプリはユーザーのウォレットソフトウェア(MetaMask、Phantom、Rainbowなど)への接続リクエストを開始します。この接続の時点ではまだ権限は付与されません。単に通信チャネルを確立するだけです。

2. チャレンジの生成

アプリは一意のチャレンジメッセージを生成します。これは通常、ランダムなナンスか、アプリのドメイン、タイムスタンプ、認証リクエストの目的を含むフォーマット済みメッセージです。これによりリプレイ攻撃を防ぎます。

3. 暗号学的署名

ユーザーのウォレットは秘密鍵を使ってチャレンジメッセージに署名します。秘密裏に保持される秘密鍵は、対応する公開鍵の所有を証明するために使用されます。この署名は、鍵自体を明かすことなく、ユーザーがウォレットアドレスに紐づく秘密鍵を管理していることを証明します。

4. 署名の検証

アプリはユーザーの公開鍵(ウォレットアドレス)を使って署名を検証します。署名が有効であれば、アプリはユーザーがそのウォレットアドレスを所有していることを確認し、アクセスを許可します。この検証は、アーキテクチャに応じてクライアント側またはバックエンドで行われます。

5. セッション管理

認証後、アプリは通常、従来のウェブセッションと同様に、以降のリクエスト用のセッショントークンを発行します。これにより、ユーザーがすべての操作ごとにメッセージに署名する必要がなくなります。

この暗号学的な基盤により、パスワードベースの認証よりもいくつかの点で安全性が高まります。データベース侵害から盗まれるパスワードが存在しません。フィッシング攻撃は、ユーザーを悪意のあるトランザクションに署名させるよう仕向ける必要があり、パスワードを盗むよりも発見されやすくなります。ユーザーは、中央集権的なプロバイダーを信頼する代わりに、自分の認証情報を自分で管理できます。

Web3認証における現在の問題点は何か?

暗号学的な利点があるにもかかわらず、web3認証にはメインストリームでの採用を制限する重大なユーザー体験上の課題があります。これらの問題を理解することは、より幅広いユーザーに機能するソリューションを構築するために不可欠です。

シードフレーズはユーザー体験にどのような影響を与えるのか?

Web3では、ユーザーがウォレットをセットアップし、秘密鍵を管理し、シードフレーズを保管し、しばしば使いにくいブラウザ拡張機能やモバイルアプリを扱う必要があります。ユーザーが12〜24個のランダムな単語を書き留めて安全に保管しなければならないシードフレーズのモデルは、メインストリームのユーザーの期待と根本的に相容れません。

データによると、ユーザーの35%がウォレットのシードフレーズを一度もバックアップしておらず、資金へのアクセスを失う深刻なリスクにさらされています。これはユーザーのミスではなく、設計上の問題です。長年、私たちはメールによる復旧でパスワードをリセットできてきました。暗号資産ウォレットでは、シードフレーズの仕組みは異なります。紛失した場合、リセットの選択肢はありません。これは、始める前に理解しておくべき重要な違いです。

なぜウォレットのUXはわかりにくいのか?

暗号資産での署名は、利用許諾契約書を読むような感覚に近く、しかも法律用語の代わりに16進コードや生の関数呼び出しが表示されます。ユーザーがウォレットで「Sign」をクリックすると、次のようなものが表示されることがよくあります。

• 16進数形式の生のトランザクションデータ
• Gweiでのガス代見積もり
• 見覚えのないコントラクトアドレス
• approve\(address,uint256\)のような関数呼び出し

ユーザーには、これらのトランザクションが正当なものか悪意のあるものかを評価するための情報がありません。この情報の非対称性がセキュリティ上の脆弱性を生みます。ユーザーは、自分が何を承認しているのか理解しないまま「Confirm」をクリックしてしまいます。

ユーザーはどのような技術的障壁に直面しているのか?

ユーザーは、ログインを試みる前から、複数のブロックチェーンネットワーク、16進数アドレス、ガス代に直面します。認知的な負荷を考えてみましょう。

• ネットワーク選択: Ethereumメインネット、Polygon、Arbitrum、Base、Optimismのどれを使うべきか?
• アドレス管理: 0x742d35Cc6634C0532925a3b844Bc9e7595f0bEbが自分のアカウントを表していると理解すること
• ガス代: 認証するためだけにネイティブトークン(ETH、MATICなど)を保有する必要があること
• ブラウザ拡張機能: 別途ウォレットソフトウェアをインストールして管理すること

これらはそれぞれ、ユーザーが離脱するポイントとなります。

ウォレットの分断はユーザーにどのような影響を与えるのか?

多くのWeb3ユーザーは、それぞれ保護が必要な、別々の鍵とリカバリーフレーズを持つ複数のウォレットを管理しています。あるユーザーは次のようなものを持っているかもしれません。

• EthereumとEVMチェーン用のウォレット1つ
• 別のSolanaウォレット
• 異なるアプリやユースケース用の異なるウォレット
• 高額資産用のハードウェアウォレット

この分断を管理するには、ほとんどのユーザーが持ち合わせていない技術的な知識と組織的な規律が必要です。

現在の認証はどのようなセキュリティリスクを生み出しているのか?

スマートコントラクトとDeFiプラットフォームはハッカーの標的になることが多く、フィッシング攻撃によってユーザーが秘密鍵を明かすよう仕向けられています。認証の仕組み自体が攻撃対象になるのは、次のような場合です。

• 承認フィッシング: ユーザーが気づかないうちに無制限のトークン承認に署名してしまう
• ドメインのなりすまし: 正規のアプリを模倣した偽サイト
• ソーシャルエンジニアリング: 攻撃者がサポートになりすましてシードフレーズを取得する
• 悪意のあるコントラクト: ユーザーがウォレットを流出させるコントラクトと関わってしまう

秘密鍵のセキュリティはWeb3において極めて重要です。秘密鍵へのアクセスを失うことは、デジタルアイデンティティと資産へのアクセスを失うことを意味しかねません。これにより、一度のミスが致命的になりうる、リスクの高い環境が生まれます。

Web3認証はどのように改善されているのか?

オンチェーンエコシステムは、セキュリティや分散性を犠牲にすることなく認証UXを大幅に改善する、いくつかの技術革新によってこれらの課題に積極的に取り組んでいます。

埋め込みウォレットとは何か?

埋め込みウォレットはWeb3アプリケーションに直接組み込まれており、馴染みのあるログイン体験を提供し、シードフレーズを記憶して保管する必要がありません。ユーザーにブラウザ拡張機能や別のウォレットアプリのインストールを求める代わりに、ウォレット機能がアプリケーションに直接統合されます。

埋め込みウォレットを使えば、ユーザーはGoogle、Apple ID、またはXのアカウントでログインすることを選択でき、裏側では自己管理型のウォレットが本人に代わって作成されます。このアプローチには、次のような重要な利点があります。

馴染みのある認証フロー

ユーザーは、メール、OAuth、生体認証など、すでに理解している方法で認証を行います。ウォレットの作成と復旧は馴染みのある認証フローで処理され、ユーザーが秘密鍵を直接理解したり管理したりする必要がなくなります。

ブラウザ拡張機能が不要

ウォレットはアプリのコンテキスト内に存在します。ユーザーはMetaMaskやその他のサードパーティソフトウェアをインストールする必要がありません。これにより、主要なオンボーディング上の障壁が取り除かれ、認証体験を完全にコントロールできるようになります。

シームレスなUX

ウォレットはアプリのUIに埋め込まれているため、ポップアップやリダイレクト画面なしで、見た目、感触、フローを完全にコントロールできます。認証は既存のユーザー体験にインラインで組み込まれます。

ソーシャルログインはどのようにWeb3アクセスを可能にするのか?

ソーシャルログイン統合は、既存の認証プロバイダーを活用することで、Web2とWeb3の間の橋渡しをします。技術的なアーキテクチャは次のように機能します。

MPCによる鍵の分割

TSS-MPC、つまりマルチパーティ計算を伴うしきい値署名方式は、複数の当事者が共同で単一のデジタル署名を生成できるようにする暗号技術的な手法であり、秘密鍵をどの単一の当事者にも明かすことなく、署名権限を参加者間に分散させることでセキュリティを高めます。

ユーザーがGoogleでサインインすると:

1. アプリがOAuthを通じてユーザーを認証します
2. システムが複数の当事者に分割された秘密鍵を生成します
3. (アプリケーション自身を含む)どの単一の当事者も鍵の全体にアクセスできません
4. トランザクション署名には、当事者間でのしきい値協力が必要です
5. ユーザーは鍵を直接管理することなく自己管理を維持します

パスキー認証

パスキーは、WebAuthn標準に基づき、従来のパスワードよりも安全で便利になるよう設計された、パスワード不要の認証方式です。パスキーは次のような公開鍵暗号方式を使用します。

• 秘密鍵はユーザーのデバイスのセキュアエンクレーブ(AppleのSecure EnclaveやAndroidのTrusted Execution Environmentなど)に保存されます
• 公開鍵は認証サーバーに保存されます
• 摩擦を生みフィッシングリスクをもたらす従来のパスワードとは異なり、パスキーは生体認証を使ってユーザーのデバイスに認証情報を安全に作成・保存するという馴染みのあるパターンを活用します

これにより、馴染みのあるUX(FaceIDやTouchID)を保ちながら、強固なセキュリティ(秘密鍵がデバイスから外に出ることはない)を提供します。

アカウント抽象化とは何か、なぜ重要なのか?

アカウント抽象化(ERC-4337)は、オンチェーンアカウントの仕組みにおける根本的な転換を表します。Account Abstractionを使用するスマートコントラクトウォレットは、単一の秘密鍵によって管理されるウォレットではなく、スマートコントラクトによって管理されるウォレットを作成します。

従来のEthereumアカウント(外部所有アカウント、すなわちEOA)は単一の秘密鍵によって制御されます。スマートコントラクトアカウントはコードによって制御され、これにより大幅に多くの機能が可能になります。

ガススポンサーシップ

アカウント抽象化により、ユーザーのウォレットまたはアカウントがプログラム可能になり、開発者はユーザーに代わってガス代をスポンサーできるようになります。これにより:

• ユーザーはアプリを操作するためにETHを保有する必要がありません
• オンボーディングのトランザクションをスポンサーして摩擦を減らすことができます
• ユーザーはステーブルコインや他のERC-20トークンでガス代を支払うことができます
• どのトランザクションをスポンサーするかについて、特定のポリシーを設定できます

トランザクションのバッチ処理

プログラム可能なスマートアカウントとして、トランザクションをバッチ処理でき、UXを大幅に簡素化し、レイテンシーを削減できます。ユーザーは次のことができます。

• トークンを承認し、単一のトランザクションでスワップする
• NFTをミントし、それをアトミックに販売リストに載せる
• 複数のウォレット確認なしで、複数ステップのDeFi戦略を実行する

ソーシャルリカバリー

スマートコントラクトアカウントは、シードフレーズに依存しない復旧メカニズムを実装できます。

• アカウントの復旧を助けてくれる信頼できる連絡先を指定する
• メールや電話ベースの復旧フローを使用する
• 時間ロック付きのアカウント復旧プロセスを実装する

プログラム可能なセキュリティ

アカウントはスマートコントラクトであるため、カスタムロジックを実装できます。

• 高額トランザクションに対するマルチシグ要件
• 1日あたりまたはトランザクションあたりの支出制限
• 自動承認のためのホワイトリスト登録済みアドレス
• 特定操作に対する時間ベースの制限

Ethereumの共同創設者であるVitalikは、EOAからSmart Walletsへの移行を、メインストリームユーザーをオンチェーンに導くための必須条件と見ています。アカウント抽象化は「あれば嬉しい」機能ではなく、メインストリーム採用のための基盤インフラです。

パスキーは認証セキュリティをどのように向上させるのか?

パスキーには、複数の組み込みセキュリティ上の利点があります。具体的には、パスワードやパスコードとは異なり、パスキーではユーザーが情報を記憶する必要がなく、その情報がユーザーからフィッシングされることもありません。

セキュリティモデルは次のように機能します。

デバイスに紐づいた認証情報

秘密鍵はデバイスのセキュアハードウェア(トラステッドプラットフォームモジュール、セキュアエンクレーブなど)で生成・保存されます。デバイスから外に出ることはないため、ネットワーク攻撃による鍵盗難のリスクがなくなります。

フィッシング耐性

パスキーは作成元のドメインに紐づいているため、フィッシングサイトでは使用できません。ユーザーが偽サイトに誘導されてしまったとしても、ドメインが一致しないため、パスキーは機能しません。

共有秘密の不使用

ユーザーとサーバーの間で共有される秘密であるパスワードとは異なり、パスキーは非対称暗号を使用します。サーバーが保存するのは公開鍵のみであり、たとえデータベースが侵害されても攻撃者にとっては無用です。

生体認証

さらに、パスキーはiCloudやGoogleアカウントに紐づいているため、AppleやGoogleのセキュリティによって保護されます。これにより:

• デフォルトで多要素認証が実現します(デバイスの所持 + 生体認証)
• SIMスワップ攻撃に対する保護
• デバイス間でのバックアップと同期

開発者向けのどのようなソリューションがWeb3認証を容易にするのか?

複数のプロバイダーが、web3認証の実装を簡素化するインフラを提供しています。この分野で知っておくべきことを紹介します。

どのようなサードパーティ認証プロバイダーがあるのか?

Web3Auth

Web3ウォレットとアプリケーションが、メインストリームのユーザーとネイティブなWeb3ユーザーの両方にシームレスなログインを提供できるようにする、シンプルで非管理型の認証インフラです。Web3Authはソーシャルログイン、メール認証をサポートし、複数のウォレットプロバイダーと統合します。

Magic

鍵管理のためのマルチパーティ計算を用いた、メールベースのウォレット作成を提供します。Magicは鍵の分割と復旧の複雑さを処理し、開発者にはシンプルなAPIを提供します。

Dynamic

ソーシャルログインとアカウント抽象化の統合をサポートする非管理型の埋め込みウォレットを提供します。Dynamicは、埋め込みウォレットと外部ウォレット接続のサポートの両方を提供します。

Privy

EVM、Solana、Bitcoinなどを横断して、あらゆるユーザーにハードウェアで保護されたSOC 2準拠のウォレットを提供します。Privyは、パスキーとハードウェアトークンのサポートによる、企業グレードのセキュリティを備えたシームレスなログインに重点を置いています。

Alchemyはどのようにスマートウォレットインフラをサポートしているのか?

AlchemyはRPC、Data API、Gas Manager、Bundlerを通じてスマートウォレットビルダーをサポートしています。ウォレットの作成と認証については、AlchemyはPrivyとパートナーシップを結んでいます。

摩擦ゼロのオンボーディングを実現する埋め込みウォレット

Privyの埋め込みウォレットを使えば、web2のような感触でありながら、内部は完全にweb3であるプロダクトを構築できます。これが実際にはどういうことか説明します。

ユーザーは次の方法でサインアップできます。

• メール認証
• ソーシャルログイン(Google、Apple、Twitter)
• パスキー(FaceID、TouchID)
• カスタム認証(独自の認証方式を持ち込む)
• 暗号資産に馴染みのあるユーザー向けの従来のウォレット接続

AlchemyとPrivyのパートナーシップについて詳しくはこちらをご覧ください。

スマートコントラクトアカウントの作成

認証後、開発者はAlchemyのBundlerとGas Managerを使ってスマートコントラクトアカウントを利用できます。

スマートコントラクトアカウントは、ガススポンサーシップ、バッチ処理されたトランザクション、プログラム可能なセキュリティといった、アカウント抽象化のすべての利点を提供します。

ガススポンサーシップの設定

プログラム可能なポリシーを通じてガスをスポンサーします。どのトランザクションをスポンサーするかを正確にコントロールできます。

ダッシュボードを通じてポリシーを設定します。

• ウォレットごと、または全体での支出制限
• 特定アドレスの許可リスト・ブロックリスト
• 特定のコントラクトとのやり取りをスポンサー
• 日次・月次の支出上限の設定

マルチチェーンサポート

Alchemyのアカウント抽象化インフラは、Ethereum、Polygon、Base、Optimism、Arbitrumを含む複数のチェーンをサポートしています。

本番環境対応のインフラ

Alchemyの業界最高水準で信頼性の高いインフラの上に構築されているため、スマートコントラクトウォレットのプリミティブは常にユーザーが利用可能な状態にあります。次のものを提供します。

• 99.99%の稼働率SLA
• サブ秒単位の応答時間
• 自動スケーリング
• エンタープライズ顧客向けの24時間365日サポート

ウォレットプロバイダーは、認証レイヤーをAlchemyのRPC、Data API、Gas Manager、Bundlerと組み合わせることができます。

Web3認証はどのように実装すべきか?

数千のアプリの認証を構築してきた経験から、本番環境で機能するパターンを紹介します。

ソーシャルログインとウォレット接続、どちらから始めるべきか?

メインストリームのユーザーを対象とするアプリの場合は、ソーシャルログインから始めましょう。暗号資産に馴染みのあるユーザーを対象とするアプリの場合は、両方をサポートしましょう。

• ソーシャルログイン優先パターン: このアプローチは、暗号資産ウォレットを持たない新規ユーザーのコンバージョンを最大化します。ウォレットを完全に自分で管理したいユーザー向けに、「MetaMaskへのエクスポート」機能を後から追加することもできます。
• ウォレット接続優先パターン: これは、ユーザーがすでにウォレットを持っている可能性が高いDeFiアプリ、NFTマーケットプレイス、その他のアプリに適しています。

ガス代はどのように扱うべきか?

ユーザーにアプリを使う前にETHを購入させないようにしましょう。ガス代をスポンサーすることで、ユーザーはETHを必要とせずに無料でアプリを試すことができます。ビジネスモデルに応じてスポンサーシップのポリシーを設定します。

フリーミアムモデル:

• ユーザーごとに最初のN件のトランザクションをスポンサー
• 無料枠を超えたら支払いまたはステーキングを要求
• 不正利用を防ぐため、ウォレットごとの支出を監視

サブスクリプションモデル:

• 有料サブスクリプションユーザーには全ガス代をスポンサー
• 無料枠のユーザーはスポンサーを制限

トランザクションベースモデル:

• 各トランザクションから手数料を徴収
• トランザクションコストの一部としてガス代をスポンサー

スムーズなUXを提供しつつコストを制御するために、全体の支出制限を設定しましょう。

トランザクションのバッチ処理を使うべきか?

はい、ユーザーが1つのフローを完了するために複数の操作が必要な場合は常に使うべきです。トランザクションは配列に現れる順に逐次実行され、次のことが可能になります。

UXの改善:

• 複数のウォレットポップアップの代わりに1回の確認
• アトミックな実行(すべての操作が成功するか、すべて失敗するか)
• 総ガスコストの削減

よくあるパターン:

• 承認+スワップ: ユーザーが1クリックで承認とスワップの実行を行えるようにする
• ミント+リスト: NFTをアトミックに作成・出品する
• マルチトークン操作: 1つのトランザクションで複数のコントラクトとやり取りする

モバイルユーザーはどのように扱うべきか?

Dynamicは、パスキーを活用した簡単なFaceIDやTouchIDでのログインとウォレット作成を実現するため、モバイルフローの最適化に時間をかけました。モバイルファーストの認証が重要な理由は次のとおりです。

• ほとんどのユーザーはモバイルデバイスからアプリにアクセスします
• 生体認証はモバイルの方がアクセスしやすいです
• モバイルウォレットアプリ(MetaMask Mobile、Rainbow)はディープリンクを必要とします

モバイルのベストプラクティス:

1. パスキーを優先する: FaceIDとTouchIDが最良のモバイルUXを提供します
2. WalletConnectをサポートする: モバイルウォレットアプリを持つユーザー向け
3. ディープリンクをテストする: ウォレットアプリへのスムーズな受け渡しを確保します
4. 小さい画面向けに設計する: 認証UIは320pxのビューポートでも機能する必要があります
5. リダイレクトを最小限に抑える: 可能な限りユーザーをアプリのコンテキスト内に留めます

段階的な開示についてはどうか?

新規ユーザーを高度な機能で圧倒しないようにしましょう。最初は独自のチェックアウトフローを設計し、バックグラウンドでトランザクションに署名し、その後徐々により多くのコントロールを開示していきます。

フェーズ1: 見えないウォレット

• ソーシャルログインのみ
• すべてのトランザクションを自動署名
• ウォレット用語を一切表示しない
• ガスを完全にスポンサー

フェーズ2: 基本的なコントロール

• トランザクション確認を表示
• ユーザーが自分のウォレットアドレスを閲覧できるようにする
• トランザクション履歴を表示
• ガススポンサーシップについて説明

フェーズ3: 高度な機能

• 外部ウォレットへのエクスポートを許可
• 高度なトランザクションの詳細を表示
• 手動でのガス支払いを有効化
• ハードウェアウォレットでの署名をサポート

このアプローチは、パワーユーザーにコントロールを提供しつつ、コンバージョンを最大化します。

Web3認証の将来はどうなるのか?

オンチェーン認証の方向性は明確です。デフォルトでは見えず、必要なときには強力である、というものです。

スマートアカウントはEOAに取って代わるのか?

Ethereumの共同創設者であるVitalikは、EOAからSmart Walletsへの移行を、メインストリームユーザーをオンチェーンに導くための必須条件と見ています。これは憶測ではなく、技術的なロードマップです。

スマートウォレットは次のものを提供します。

• プログラム可能な権限によるより優れたセキュリティ
• ガス抽象化とバッチ処理による優れたUX
• シードフレーズなしのアカウント復旧
• クロスチェーンの相互運用性

エコシステムはスマートウォレットをデフォルトとする方向に進んでいます。EOAは下位互換性のためにサポートされ続けますが、新しいアプリはスマートウォレットインフラの上に構築すべきです。

チェーン抽象化は認証にどのような影響を与えるのか?

チェーン抽象化は、鍵、復旧フレーズ、複数のウォレットなしで、ユーザーが一度でサインアップできるようにすることで問題を解決します。ユーザーは自分がどのチェーンを使っているかを知る必要がなくなるべきです。

将来の認証は次のようになります。

• すべてのチェーンで同じアカウントアドレスを使用する
• チェーン固有の詳細を抽象化する
• トランザクションを自動的に最適なチェーンにルーティングする
• クロスチェーン操作を透過的に処理する

これにはウォレットプロバイダー、ブリッジ、アプリケーション間の連携が必要ですが、その技術的な基盤は今まさに構築されつつあります。

生体認証は標準になるのか?

ユーザーはFace IDやTouch IDによる生体認証を通じて、自己管理型のウォレットを生成できます。パスキーはすでにApple、Google、Microsoftによってサポートされており、採用が加速しています。

2〜3年以内には、次のようなことが予想されます。

• パスキーがデフォルトの認証方式になる
• シードフレーズは、それを求める上級ユーザーのみが使用する
• すべてのデバイスで生体認証が使えるようになる
• iCloud/Googleアカウントを介したシームレスな同期

AIはどのような役割を果たすのか?

AIエージェントは、混沌としたDeFiのスパゲッティ状態を、シームレスで人間に優しい金融に変えることができ、暗号資産を技術的に可能なだけでなく、実際に使えるものにすることができます。AIは次のような形で認証に影響を与えます。

トランザクション意図の解析:

• ユーザーは自然言語でやりたいことを説明する
• AIが適切なトランザクションを生成する
• ユーザーはシンプルな確認操作で承認する

不正検知:

• AIがトランザクションのパターンを分析して異常を検出する
• ユーザーが疑わしいトランザクションを承認する前に警告する
• 過去の攻撃から学習し、新たな攻撃を防ぐ

パーソナライズされたセキュリティ:

• リスクレベルに基づく適応型認証
• AIが推奨するセキュリティ設定
• 自動化されたセキュリティ監視

今日から構築を始めるにはどうすればよいか?

web3の約束とそのユーザー体験の間のギャップは急速に縮まりつつあります。最新の認証インフラにより、分散性やセキュリティを犠牲にすることなく、メインストリームのユーザーをオンボーディングすることが可能になっています。

Alchemyは、このスタックを次のもので支えています。

• ブロックチェーンアクセスのためのRPCとData API
• プログラム可能なガススポンサーシップのためのGas Manager
• ユーザーオペレーションを送信するためのBundler
• サポート対象ネットワーク全体にわたるマルチチェーンインフラ

数千の開発者が私たちのインフラを使って数百万人のユーザーをオンボーディングしています。認証の未来は、ユーザーにブロックチェーンの仕組みを教えることではありません。それは、ユーザーが基盤となる技術について考える必要がないほど直感的なシステムを構築することです。

最新のweb3認証を実装する準備はできましたか? 開発者アカウントのサインアップを行い、ドキュメントから始め、詳細情報や導入支援についてはお問い合わせください。

よくある質問

アプリにウォレットベースの認証を追加するための基本的な手順は?

ウォレット接続フローを統合し、ユーザーに一意のメッセージに署名させ、そのバックエンドで署名を検証し、その後ユーザーがすべてのリクエストごとに再署名することなくログイン状態を保てるようセッショントークンを作成します。

メッセージへの署名はどのようにユーザーのウォレット所有を証明するのか?

アプリは、そのウォレットの秘密鍵の保有者のみが署名できるチャレンジメッセージを送信し、その後アプリはウォレットの公開アドレスで署名を検証し、ユーザーがそのアドレスを管理していることを確認します。

Web3認証にはソーシャルログイン、ウォレットログイン、それとも両方を使うべきか?

メインストリームのユーザー層向けには、ソーシャルログインから始め、任意で裏側でウォレットを作成するとよいでしょう。一方、暗号資産に馴染みのあるアプリでは、直接的なウォレット接続を優先し、ソーシャルログインをフォールバックとして追加することがよくあります。

ユーザーがウォレットで認証した後、セッションはどのように管理すればよいか?

署名されたメッセージを検証した後、従来のウェブセッションと同様に、以降のAPIリクエスト用のセッショントークンまたはCookieを発行し、ユーザーがすべての操作ごとに署名する必要がないようにします。

埋め込みウォレットとは何か、認証をどのように改善するのか?

埋め込みウォレットはアプリケーションに直接組み込まれており、ユーザーはGoogleやApple IDといった馴染みのある方法で認証でき、その裏側で自己管理型のウォレットが作成されます。これにより、ブラウザ拡張機能やシードフレーズの管理が不要になります。

パスキーはWeb3認証をどのようにより安全にするのか?

パスキーは、デバイスから外に出ることのないセキュアハードウェアに保存されたデバイス紐づけの認証情報を使用し、フィッシング攻撃に対する耐性があり、サーバーと秘密を共有することなく生体認証を提供します。

アカウント抽象化とは何か、なぜ認証にとって重要なのか?

アカウント抽象化は、ガス代のスポンサー、トランザクションのバッチ処理、ソーシャルリカバリーのようなプログラム可能なセキュリティ機能の実装を可能にするスマートコントラクトアカウントを実現し、メインストリームでの採用を妨げていた多くの障壁を取り除きます。

ユーザー認証のためにガス代をスポンサーすべきか?

はい。ガス代をスポンサーすることで、暗号資産を持たない新規ユーザーにとっての大きな障壁が取り除かれ、最初にETHを購入する必要なくアプリを試すことができるようになります。