Web2認証にイーサリアムを使用する

web2

認証

eas

初級

Ori Pomerantz

2025年4月30日

31 分の読書

はじめに

SAML (opens in a new tab)は、Web2でIDプロバイダー (IdP) (opens in a new tab) がサービスプロバイダー (SP) (opens in a new tab)にユーザー情報を提供するために使用される標準です。

このチュートリアルでは、イーサリアム署名をSAMLと統合し、まだイーサリアムをネイティブにサポートしていないWeb2サービスに対して、ユーザーがイーサリアムウォレットを使用して認証できるようにする方法を学びます。

このチュートリアルは、2つの異なる読者を対象に書かれていることに注意してください。

イーサリアムを理解していて、SAMLを学ぶ必要があるイーサリアム関係者
SAMLとWeb2認証を理解していて、イーサリアムを学ぶ必要があるWeb2関係者

そのため、すでにご存知の入門的な内容が多く含まれています。適宜読み飛ばしてください。

イーサリアム関係者向けのSAML

SAMLは中央集権型のプロトコルです。サービスプロバイダー (SP) は、IDプロバイダー (IdP) との間、またはそのIdPの証明書に署名した証明書認証局 (opens in a new tab)との間に、既存の信頼関係がある場合にのみ、IdPからのアサーション (「これは私のユーザーJohnで、A、B、Cを行う権限を持つべきである」など) を受け入れます。

たとえば、SPは企業に旅行サービスを提供する旅行代理店、IdPは企業の社内ウェブサイトであるとします。従業員が出張の予約をする際、旅行代理店は、実際に旅行の予約を許可する前に、従業員を会社の認証に送ります。

これが、ブラウザ、SP、IdPの3つのエンティティがアクセスを交渉する方法です。 SPは、ブラウザを使用しているユーザーについて事前に何も知る必要はなく、IdPを信頼するだけで済みます。

SAML関係者向けのイーサリアム

イーサリアムは分散型システムです。

ユーザーは秘密鍵を持っています (通常はブラウザ拡張機能に保存されています)。秘密鍵から公開鍵を導出し、そこから20バイトのアドレスを導出できます。ユーザーがシステムにログインする必要がある場合、ノンス (1回限りの値) を持つメッセージに署名するよう要求されます。サーバーは、署名がそのアドレスによって作成されたことを検証できます。

署名はイーサリアムアドレスを検証するだけです。他のユーザー属性を取得するには、通常アテステーション (opens in a new tab)を使用します。アテステーションには通常、以下のフィールドがあります。

証明者、アテステーションを行ったアドレス
受取人、アテステーションが適用されるアドレス
データ、名前や権限など、証明されるデータ
スキーマ、データの解釈に使用されるスキーマのID。

イーサリアムの分散型の性質により、どのユーザーでもアテステーションを作成できます。どのアテステーションが信頼できるかを判断するには、証明者のIDが重要です。

セットアップ

最初のステップは、SAML SPとSAML IdPが互いに通信できるようにすることです。

ソフトウェアをダウンロードします。この記事のサンプルソフトウェアは、github (opens in a new tab)にあります。異なるステージは異なるブランチに保存されています。このステージでは saml-only を使用します。
```
git clone https://github.com/qbzzt/250420-saml-ethereum -b saml-only
cd 250420-saml-ethereum
pnpm install
```
自己署名証明書でキーを作成します。これは、キーがそれ自体の証明書認証局であることを意味し、サービスプロバイダーに手動でインポートする必要があります。詳細については、OpenSSLのドキュメント (opens in a new tab)を参照してください。
```
mkdir keys
cd keys
openssl req -new -x509 -days 365 -nodes -sha256 -out saml-sp.crt -keyout saml-sp.pem -subj /CN=sp/
openssl req -new -x509 -days 365 -nodes -sha256 -out saml-idp.crt -keyout saml-idp.pem -subj /CN=idp/
cd ..
```
サーバー (SPとIdPの両方) を起動します。
```
pnpm start
```
URL http://localhost:3000/ (opens in a new tab)でSPにアクセスし、ボタンをクリックしてIdP (ポート3001) にリダイレクトします。
IdPにメールアドレスを入力し、サービスプロバイダーにログインをクリックします。サービスプロバイダー (ポート3000) にリダイレクトされ、メールアドレスで認識されていることを確認します。

詳細な説明

ステップバイステップで起こることは次のとおりです。

src/config.mts

このファイルには、IDプロバイダーとサービスプロバイダー両方の設定が含まれています。通常、これら2つは異なるエンティティですが、ここでは簡潔にするためにコードを共有します。

const fs = await import("fs")

const protocol="http"

今のところテストだけなので、HTTPを使用して問題ありません。

export const spCert = fs.readFileSync("keys/saml-sp.crt").toString()
export const idpCert = fs.readFileSync("keys/saml-idp.crt").toString()

通常は両方のコンポーネントで利用可能な公開鍵 (直接信頼されるか、信頼された証明書認証局によって署名される) を読み取ります。

export const spPort = 3000
export const spHostname = "localhost"
export const spDir = "sp"

export const idpPort = 3001
export const idpHostname = "localhost"
export const idpDir = "idp"

export const spUrl = `${protocol}://${spHostname}:${spPort}/${spDir}`
export const idpUrl = `${protocol}://${idpHostname}:${idpPort}/${idpDir}`

両コンポーネントのURLです。

export const spPublicData = {

サービスプロバイダーの公開データです。

    entityID: `${spUrl}/metadata`,

慣例的に、SAMLではentityIDはエンティティのメタデータが利用可能なURLです。このメタデータはここの公開データに対応しますが、XML形式である点が異なります。

    wantAssertionsSigned: true,
    authnRequestsSigned: false,
    signingCert: spCert,
    allowCreate: true,
    assertionConsumerService: [{
        Binding: 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST',
        Location: `${spUrl}/assertion`,
    }]
  }

私たちの目的にとって最も重要な定義は assertionConsumerServer です。これは、サービスプロバイダーに何かをアサートする (例えば、「この情報を送信するユーザーは somebody@example.com (opens email client) です」) ためには、URL http://localhost:3000/sp/assertion に HTTP POST (opens in a new tab) を使用する必要があることを意味します。

export const idpPublicData = {
    entityID: `${idpUrl}/metadata`,
    signingCert: idpCert,
    wantAuthnRequestsSigned: false,
    singleSignOnService: [{
      Binding: "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST",
      Location: `${idpUrl}/login`
    }],
    singleLogoutService: [{
      Binding: "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST",
      Location: `${idpUrl}/logout`
    }],
  }

IDプロバイダーの公開データも同様です。これは、ユーザーをログインさせるには http://localhost:3001/idp/login にPOSTし、ユーザーをログアウトさせるには http://localhost:3001/idp/logout にPOSTすることを指定しています。

src/sp.mts

これはサービスプロバイダーを実装するコードです。

import * as config from "./config.mts"
const fs = await import("fs")
const saml = await import("samlify")

SAMLを実装するために samlify (opens in a new tab) ライブラリを使用します。

import * as validator from "@authenio/samlify-node-xmllint"
saml.setSchemaValidator(validator)

samlify ライブラリは、XMLが正しいこと、期待される公開鍵で署名されていることなどを検証するパッケージを必要とします。この目的のために @authenio/samlify-node-xmllint (opens in a new tab) を使用します。

const express = (await import("express")).default
const spRouter = express.Router()
const app = express()

express (opens in a new tab)の Router (opens in a new tab)は、ウェブサイト内にマウントできる「ミニウェブサイト」です。この場合、すべてのサービスプロバイダーの定義をグループ化するために使用します。

const spPrivateKey = fs.readFileSync("keys/saml-sp.pem").toString()

const sp = saml.ServiceProvider({
  privateKey: spPrivateKey,  
  ...config.spPublicData
})

サービスプロバイダー自身の表現は、すべての公開データと、情報に署名するために使用する秘密鍵です。

const idp = saml.IdentityProvider(config.idpPublicData);

公開データには、サービスプロバイダーがIDプロバイダーについて知る必要があるすべてのものが含まれています。

spRouter.get(`/metadata`, 
  (req, res) => res.header("Content-Type", "text/xml").send(sp.getMetadata())
)

他のSAMLコンポーネントとの相互運用性を確保するため、サービスプロバイダーとIDプロバイダーは、公開データ (メタデータと呼ばれる) をXML形式で /metadata にて利用可能にする必要があります。

spRouter.post(`/assertion`,

これは、ブラウザが自身を識別するためにアクセスするページです。アサーションにはユーザー識別子 (ここではメールアドレスを使用) が含まれ、追加の属性を含めることもできます。これは、上記のシーケンス図のステップ7のハンドラです。

  async (req, res) => {
    // console.log(`SAML response:\n${Buffer.from(req.body.SAMLResponse, 'base64').toString('utf-8')}`)

コメントアウトされたコマンドを使用して、アサーションで提供されるXMLデータを確認できます。これはbase64でエンコード (opens in a new tab)されています。

    try {
      const loginResponse = await sp.parseLoginResponse(idp, 'post', req);

IDサーバーからのログインリクエストを解析します。

      res.send(`
        <html>
          <body>
            <h2>Hello ${loginResponse.extract.nameID}</h2>
          </body>
        </html>
      `)
      res.send();

ユーザーにログインが成功したことを示すために、HTMLレスポンスを送信します。

    } catch (err) {
      console.error('Error processing SAML response:', err);
      res.status(400).send('SAML authentication failed');
    }
  }
)

失敗した場合は、ユーザーに通知します。

spRouter.get('/login',

ブラウザがこのページを取得しようとするときに、ログインリクエストを作成します。これは、上記のシーケンス図のステップ1のハンドラです。

  async (req, res) => {
    const loginRequest = await sp.createLoginRequest(idp, "post")

ログインリクエストをPOSTするための情報を取得します。

    res.send(`
      <html>
        <body>
          <script>
            window.onload = function () { document.forms[0].submit(); }            
          </script>

このページは、フォーム (下記参照) を自動的に送信します。これにより、ユーザーはリダイレクトされるために何もする必要がありません。これは、上記のシーケンス図のステップ2です。

          <form method="post" action="${loginRequest.entityEndpoint}">

loginRequest.entityEndpoint (IDプロバイダーエンドポイントのURL) にPOSTします。

            <input type="hidden" name="${loginRequest.type}" value="${loginRequest.context}" />

入力名は loginRequest.type (SAMLRequest) です。そのフィールドのコンテンツは loginRequest.context で、これもbase64エンコードされたXMLです。

          </form>
        </body>
      </html>
    `)    
  }
)

app.use(express.urlencoded({extended: true}))

このミドルウェア (opens in a new tab) は HTTPリクエスト (opens in a new tab)のボディを読み取ります。ほとんどのリクエストはそれを必要としないため、Expressはデフォルトでそれを無視します。 POSTはボディを使用するため、これが必要です。

app.use(`/${config.spDir}`, spRouter)

サービスプロバイダーディレクトリ (/sp) にルーターをマウントします。

app.get("/", (req, res) => {
  res.send(`
    <html>
      <body>
        <button onClick="document.location.href='${config.spUrl}/login'">
           ここをクリックしてログオン
        </button>
      </body>
    </html>
  `)
})

ブラウザがルートディレクトリを取得しようとした場合は、ログインページへのリンクを提供します。

app.listen(config.spPort, () => {
  console.log(`service provider is running on http://${config.spHostname}:${config.spPort}`)
})

このExpressアプリケーションで spPort をリッスンします。

src/idp.mts

これはIDプロバイダーです。これはサービスプロバイダーと非常によく似ており、以下の説明は異なる部分についてです。

const xmlParser = new (await import("fast-xml-parser")).XMLParser(
  {
    ignoreAttributes: false, // Preserve attributes
    attributeNamePrefix: "@_", // Prefix for attributes
  }
)

サービスプロバイダーから受け取ったXMLリクエストを読み取り、理解する必要があります。

const getLoginPage = requestId => `

この関数は、上記のシーケンス図のステップ4で返される、自動送信フォーム付きのページを作成します。

<html>
  <head>
    <title>ログインページ</title>
  </head>
  <body>
    <h2>ログインページ</h2>
    <form method="post" action="./loginSubmitted">
      <input type="hidden" name="requestId" value="${requestId}" />
      メールアドレス: <input name="email" />
      <br />
      <button type="Submit">
        サービスプロバイダーにログイン
      </button>

サービスプロバイダーに送信するフィールドは2つあります。

応答する requestId。
ユーザー識別子 (ここではユーザーが提供するメールアドレスを使用)。

    </form>
  </body>
</html>

const idpRouter = express.Router()

idpRouter.post("/loginSubmitted", async (req, res) => {
  const loginResponse = await idp.createLoginResponse(

これは、上記のシーケンス図のステップ5のハンドラです。 idp.createLoginResponse (opens in a new tab)はログインレスポンスを作成します。

    sp, 
    {
      authnContextClassRef: 'urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport',
      audience: sp.entityID,

オーディエンスはサービスプロバイダーです。

      extract: {
        request: {
          id: req.body.requestId
        }
      },

リクエストから抽出された情報です。リクエストで重要なパラメータはrequestIdで、これによりサービスプロバイダーはリクエストとそのレスポンスを一致させることができます。

      signingKey: { privateKey: idpPrivateKey, publicKey: config.idpCert }  // Ensure signing

レスポンスに署名するためのデータを持つために signingKey が必要です。サービスプロバイダーは署名されていないリクエストを信頼しません。

    },
    "post",
    {
      email: req.body.email

これは、サービスプロバイダーに送り返すユーザー情報を持つフィールドです。

    }
  );

  res.send(`
    <html>
      <body>
        <script>
          window.onload = function () { document.forms[0].submit(); }
        </script>
        
        <form method="post" action="${loginResponse.entityEndpoint}">
          <input type="hidden" name="${loginResponse.type}" value="${loginResponse.context}" />
        </form>
      </body>
    </html>
  `)
})

ここでも、自動送信フォームを使用します。これは、上記のシーケンス図のステップ6です。


// ログインリクエスト用のIdPエンドポイント
idpRouter.post(`/login`,

これはサービスプロバイダーからログインリクエストを受け取るエンドポイントです。これは、上記のシーケンス図のステップ3のハンドラです。

  async (req, res) => {
    try {
      // parseLoginRequestが動作しなかったための回避策
      // const loginRequest = await idp.parseLoginRequest(sp, 'post', req)
      const samlRequest = xmlParser.parse(Buffer.from(req.body.SAMLRequest, 'base64').toString('utf-8'))
      res.send(getLoginPage(samlRequest["samlp:AuthnRequest"]["@_ID"]))

idp.parseLoginRequest (opens in a new tab)を使用して認証リクエストのIDを読み取ることができるはずです。しかし、動作させることができず、それに多くの時間を費やす価値もなかったので、汎用XMLパーサー (opens in a new tab)を使用します。必要な情報は、XMLのトップレベルにある <samlp:AuthnRequest> タグ内の ID 属性です。

イーサリアム署名の使用

ユーザーIDをサービスプロバイダーに送信できるようになったので、次のステップは信頼できる方法でユーザーIDを取得することです。 Viemを使用すると、ウォレットにユーザーアドレスを尋ねるだけで済みますが、これはブラウザに情報を要求することを意味します。私たちはブラウザを制御していないため、そこから得られる応答を自動的に信頼することはできません。

代わりに、IdPはブラウザに署名するための文字列を送信します。ブラウザのウォレットがこの文字列に署名すれば、それが本当にそのアドレスであること (つまり、そのアドレスに対応する秘密鍵を知っていること) を意味します。

これを実際に確認するには、既存のIdPとSPを停止し、次のコマンドを実行します。

git checkout eth-signatures
pnpm install
pnpm start

次に、SP (opens in a new tab)にアクセスし、指示に従ってください。

この時点では、イーサリアムアドレスからメールアドレスを取得する方法がわからないため、代わりに <イーサリアムアドレス>@bad.email.address をSPに報告します。

詳細な説明

変更点は、前の図のステップ4-5にあります。

変更したファイルは idp.mts だけです。以下が変更された部分です。

import { v4 as uuidv4 } from 'uuid'
import { verifyMessage } from 'viem'

これら2つの追加ライブラリが必要です。 nonce (opens in a new tab)値を作成するために uuid (opens in a new tab) を使用します。値自体は問題ではなく、一度しか使用されないという事実が重要です。

viem (opens in a new tab) ライブラリを使用すると、イーサリアムの定義を使用できます。ここでは、署名が実際に有効であることを検証するためにこれが必要です。

const loginPrompt = "サービスプロバイダーにアクセスするには、このノンスに署名してください: "

ウォレットは、ユーザーにメッセージに署名する許可を求めます。ノンスだけのメッセージはユーザーを混乱させる可能性があるため、このプロンプトを含めます。

// ここにrequestIDを保持する
let nonces = {}

応答するためには、リクエスト情報が必要です。リクエストと一緒に送信し (ステップ4)、それを受け取る (ステップ5) こともできます。しかし、潜在的に敵対的なユーザーの制御下にあるブラウザから得られる情報は信頼できません。したがって、ノンスをキーとしてここに保存する方が良いでしょう。

簡潔さのために、ここでは変数としてこれを行っていることに注意してください。ただし、これにはいくつかの欠点があります。

サービス拒否攻撃に対して脆弱です。悪意のあるユーザーが複数回ログオンを試み、メモリを使い果たす可能性があります。
IdPプロセスを再起動する必要がある場合、既存の値を失います。
各プロセスが独自の変数を持つため、複数のプロセス間で負荷分散を行うことはできません。

本番システムでは、データベースを使用し、何らかの有効期限メカニズムを実装します。

const getSignaturePage = requestId => {
  const nonce = uuidv4()
  nonces[nonce] = requestId

ノンスを作成し、後で使用するために requestId を保存します。

  return `
<html>
  <head>
    <script type="module">

このJavaScriptは、ページが読み込まれると自動的に実行されます。

      import { createWalletClient, custom, getAddress } from 'https://esm.sh/viem'

viemからいくつかの関数が必要です。

      if (!window.ethereum) {
          alert("MetaMaskまたは互換性のあるウォレットをインストールしてからリロードしてください")
      }

ブラウザにウォレットがある場合にのみ機能します。

      const [account] = await window.ethereum.request({method: 'eth_requestAccounts'})

ウォレット (window.ethereum) からアカウントのリストを要求します。少なくとも1つあると仮定し、最初のものだけを保存します。

      const walletClient = createWalletClient({
          account,
          transport: custom(window.ethereum)
      })

ブラウザウォレットとやり取りするためのウォレットクライアント (opens in a new tab)を作成します。

      window.goodSignature = () => {
        walletClient.signMessage({
            message: "${loginPrompt}${nonce}"

ユーザーにメッセージへの署名を依頼します。このHTML全体がテンプレート文字列 (opens in a new tab)内にあるため、idpプロセスで定義された変数を使用できます。これはシーケンス図のステップ4.5です。

        }).then(signature => {
            const path= "/${config.idpDir}/signature/${nonce}/" + account + "/" + signature
            window.location.href = path
        })
      }

/idp/signature/<nonce>/<address>/<signature> にリダイレクトします。これはシーケンス図のステップ5です。

      window.badSignature = () => {
        const path= "/${config.idpDir}/signature/${nonce}/" + 
          getAddress("0x" + "BAD060A7".padEnd(40, "0")) + 
          "/0x" + "BAD0516".padStart(130, "0")
        window.location.href = path
      }

署名はブラウザから返送されますが、これは潜在的に悪意のある可能性があります (ブラウザで http://localhost:3001/idp/signature/bad-nonce/bad-address/bad-signature を開くのを止めるものは何もありません)。したがって、IdPプロセスが不正な署名を正しく処理することを確認することが重要です。

    </script>
  </head>
  <body>
    <h2>署名してください</h2>
    <button onClick="window.goodSignature()">
      良好な (有効な) 署名を送信
    </button>
    <br/>
    <button onClick="window.badSignature()">
      不正な (無効な) 署名を送信
    </button>
  </body>
</html>  
`
}

残りは標準のHTMLです。

idpRouter.get("/signature/:nonce/:account/:signature", async (req, res) => {

これはシーケンス図のステップ5のハンドラです。

  const requestId = nonces[req.params.nonce]
  if (requestId === undefined) {
    res.send("Bad nonce")
    return ;
  }  
  
  nonces[req.params.nonce] = undefined

リクエストIDを取得し、再利用されないように nonces からノンスを削除します。

  try {

署名が無効になる方法が非常に多いため、これを try ... でラップします。 catch`ブロックで、スローされたエラーをキャッチします。

    const validSignature = await verifyMessage({
      address: req.params.account,
      message: `${loginPrompt}${req.params.nonce}`,
      signature: req.params.signature
    })

シーケンス図のステップ5.5を実装するには、verifyMessage (opens in a new tab) を使用します。

    if (!validSignature)
      throw("Bad signature")
  } catch (err) {
    res.send("Error:" + err)
    return ;
  }

ハンドラの残りの部分は、1つの小さな変更を除いて、以前に /loginSubmitted ハンドラで行ったことと同等です。

  const loginResponse = await idp.createLoginResponse(
      .
      .
      .
    {
      email: req.params.account + "@bad.email.address"
    }
  );

実際のメールアドレスは持っていないので (次のセクションで取得します)、今のところはイーサリアムアドレスを返し、それがメールアドレスではないことを明確にマークします。

// ログインリクエスト用のIdPエンドポイント
idpRouter.post(`/login`,
  async (req, res) => {
    try {
      // parseLoginRequestが動作しなかったための回避策
      // const loginRequest = await idp.parseLoginRequest(sp, 'post', req)
      const samlRequest = xmlParser.parse(Buffer.from(req.body.SAMLRequest, 'base64').toString('utf-8'))
      res.send(getSignaturePage(samlRequest["samlp:AuthnRequest"]["@_ID"]))
    } catch (err) {
      console.error('SAMLレスポンスの処理中にエラーが発生しました:', err);
      res.status(400).send('SAML認証に失敗しました');
    }
  }
)

ステップ3のハンドラでは、getLoginPage の代わりに getSignaturePage を使用します。

メールアドレスの取得

次のステップは、サービスプロバイダーによって要求された識別子であるメールアドレスを取得することです。そのためには、Ethereum Attestation Service (EAS) (opens in a new tab) を使用します。

アテステーションを取得する最も簡単な方法は、GraphQL API (opens in a new tab)を使用することです。このクエリを使用します。

query GetAttestationsByRecipient {
  attestations(
    where: { 
      recipient: { equals: "${getAddress(ethAddr)}" }
      schemaId: { equals: "0xfa2eff59a916e3cc3246f9aec5e0ca00874ae9d09e4678e5016006f07622f977" }
    }
    take: 1
  ) { 
    data
    id
    attester
  }
}

このschemaId (opens in a new tab)には、メールアドレスのみが含まれます。このクエリは、このスキーマのアテステーションを要求します。アテステーションのサブジェクトは recipient と呼ばれます。これは常にイーサリアムアドレスです。

警告：ここでアテステーションを取得する方法には、2つのセキュリティ上の問題があります。

中央集権的なコンポーネントであるAPIエンドポイント https://optimism.easscan.org/graphql にアクセスしています。 id属性を取得し、オンチェーンでルックアップしてアテステーションが本物であることを確認できますが、APIエンドポイントは、アテステーションについて通知しないことで、依然としてアテステーションを検閲できます。

この問題は解決不可能ではありません。独自のGraphQLエンドポイントを実行し、チェーンログからアテステーションを取得できますが、私たちの目的には過剰です。
私たちは証明者のIDを見ていません。誰でも偽の情報を私たちに与えることができます。実際の環境では、信頼できる証明者のセットを持ち、彼らのアテステーションのみを参照します。

これを実際に確認するには、既存のIdPとSPを停止し、次のコマンドを実行します。

git checkout email-address
pnpm install
pnpm start

次に、メールアドレスを入力します。これを行うには2つの方法があります。

秘密鍵を使用してウォレットをインポートし、テスト用の秘密鍵 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80 を使用します。
自分のメールアドレスにアテステーションを追加します。
1. アテステーションエクスプローラーのスキーマ (opens in a new tab)に移動します。
2. スキーマで証明をクリックします。
3. 受信者としてイーサリアムアドレスを入力し、メールアドレスとしてメールアドレスを入力し、オンチェーンを選択します。次に、アテステーションを作成をクリックします。
4. ウォレットでトランザクションを承認します。ガスを支払うために、Optimism Blockchain (opens in a new tab)にETHが必要です。

どちらの場合も、これを行った後、http://localhost:3000 (opens in a new tab) にアクセスして指示に従ってください。テスト用の秘密鍵をインポートした場合、受け取るメールは test_addr_0@example.com です。独自のアドレスを使用した場合は、証明した内容になります。

詳細な説明

新しいステップはGraphQL通信、ステップ5.6と5.7です。

再度、idp.mtsの変更部分を示します。

import { GraphQLClient } from 'graphql-request'
import { SchemaEncoder } from '@ethereum-attestation-service/eas-sdk'

必要なライブラリをインポートします。

const graphqlEndpointUrl = "https://optimism.easscan.org/graphql"

各ブロックチェーンに個別のエンドポイント (opens in a new tab)があります。

const graphqlClient = new GraphQLClient(graphqlEndpointUrl, { fetch })

エンドポイントのクエリに使用できる新しいGraphQLClientクライアントを作成します。

const graphqlSchema = 'string emailAddress'
const graphqlEncoder = new SchemaEncoder(graphqlSchema)

GraphQLは、バイトを持つ不透明なデータオブジェクトのみを提供します。それを理解するためにはスキーマが必要です。

const ethereumAddressToEmail = async ethAddr => {

イーサリアムアドレスからメールアドレスを取得する関数です。

  const query = `
    query GetAttestationsByRecipient {

これはGraphQLクエリです。

      アテステーション(

アテステーションを探しています。

        where: { 
          recipient: { equals: "${getAddress(ethAddr)}" }
          schemaId: { equals: "0xfa2eff59a916e3cc3246f9aec5e0ca00874ae9d09e4678e5016006f07622f977" }
        }

必要なアテステーションは、私たちのスキーマにあり、受信者がgetAddress(ethAddr)であるものです。 getAddress (opens in a new tab)関数は、アドレスが正しいチェックサム (opens in a new tab)を持つことを保証します。 GraphQLは大文字と小文字を区別するため、これは必要です。「0xBAD060A7」、「0xBad060A7」、および「0xbad060a7」は異なる値です。

        take: 1

見つかったアテステーションの数に関係なく、最初のものだけが必要です。

      ) {
        data
        id
        attester
      }
    }`

受け取りたいフィールドです。

attester: アテステーションを送信したアドレス。通常、これはアテステーションを信頼するかどうかを決定するために使用されます。
id: アテステーションID。この値を使用して、アテステーションをオンチェーンで読み取り (opens in a new tab)、GraphQLクエリからの情報が正しいことを確認できます。
data: スキーマデータ (この場合はメールアドレス)。

  const queryResult = await graphqlClient.request(query)

  if (queryResult.attestations.length == 0)
    return "no_address@available.is"

アテステーションがない場合は、明らかに不正であるが、サービスプロバイダーには有効に見える値を返します。

  const attestationDataFields = graphqlEncoder.decodeData(queryResult.attestations[0].data)
  return attestationDataFields[0].value.value
}

値がある場合は、decodeDataを使用してデータをデコードします。提供されるメタデータは不要で、値自体のみが必要です。

  const loginResponse = await idp.createLoginResponse(
    sp, 
    {
      .
      .
      .
    },
    "post",
    {
      email: await ethereumAddressToEmail(req.params.account)
    }
  );

新しい関数を使用してメールアドレスを取得します。

分散化については？

この構成では、イーサリアムとメールアドレスのマッピングに信頼できる証明者に依存している限り、ユーザーは他人になりすますことはできません。しかし、私たちのIDプロバイダーは依然として中央集権的なコンポーネントです。 IDプロバイダーの秘密鍵を持っている人は誰でも、サービスプロバイダーに偽の情報を送信できます。

マルチパーティ計算 (MPC) (opens in a new tab) を使用した解決策があるかもしれません。将来のチュートリアルでそれについて書きたいと思っています。

まとめ

イーサリアム署名のようなログオン標準の採用は、鶏が先か卵が先かの問題に直面します。サービスプロバイダーは、可能な限り広い市場にアピールしたいと考えています。ユーザーは、ログオン標準のサポートを心配することなく、サービスにアクセスできることを望んでいます。イーサリアムIdPなどのアダプターを作成することは、このハードルを乗り越えるのに役立ちます。

私の他の作品はこちらでご覧いただけます (opens in a new tab).

ページの最終更新: 2026年4月3日

Web2認証にイーサリアムを使用する

はじめに

イーサリアム関係者向けのSAML

SAML関係者向けのイーサリアム

セットアップ

詳細な説明

src/config.mts

src/sp.mts

src/idp.mts

イーサリアム署名の使用

詳細な説明

メールアドレスの取得

詳細な説明

分散化については？

まとめ

このチュートリアルは役に立ちましたか？