Webflow アプリケーションへ認証機能の追加

このガイドでは、Logto を Webflow サイトに統合する方法を紹介します。

ヒント:

サンプルプロジェクトは Webflow プロジェクトプレビューで利用可能です。

前提条件

Webflow と Logto を統合するには、Webflow の「カスタムコード」機能が必要で、少なくとも「Basic」プランが必要です。
Webflow サイト。既存のサイトを使用するか、新しいサイトを作成します。

統合

Logto プロバイダーの初期化

注記:

以下の手順では、あなたの Webflow サイトが https://your-awesome-site.webflow.io で動作していると仮定します。

このステップでは、Webflow サイトにグローバルレベルのカスタムコードを追加します。Webflow では NPM がサポートされていないため、Logto SDK をインポートするために jsdelivr.com CDN サービスを使用します。

「サイト設定」ページを開き、「カスタムコード」セクションに移動します。「ヘッドコード」セクションに次のコードを追加します。

<script type="module">
  // jsdelivr CDN から \`@logto/browser\` SDK をインポート
  import LogtoClient from 'https://esm.run/@logto/browser';

  // \`logtoClient\` インスタンスを window オブジェクトに割り当て、
  // 他のページでのグローバルな使用を可能にする
  window.logtoClient = new LogtoClient({
    endpoint: '<your-logto-endpoint>', // 例: http://localhost:3001
    appId: '<your-application-id>',
  });
</script>

詳細に入る前に、エンドユーザーの体験について簡単に説明します。サインインプロセスは次のように簡略化できます：

あなたのアプリがサインインメソッドを呼び出します。
ユーザーは Logto のサインインページにリダイレクトされます。ネイティブアプリの場合、システムブラウザが開かれます。
ユーザーがサインインし、あなたのアプリにリダイレクトされます（リダイレクト URI として設定されています）。

この認証 (Authentication) プロセスは OpenID Connect (OIDC) プロトコルに従い、Logto はユーザーのサインインを保護するために厳格なセキュリティ対策を講じています。
複数のアプリがある場合、同じアイデンティティプロバイダー (Logto) を使用できます。ユーザーがあるアプリにサインインすると、Logto は別のアプリにアクセスした際に自動的にサインインプロセスを完了します。

リダイレクトベースのサインインの理論と利点について詳しく知るには、Logto サインイン体験の説明を参照してください。

Logto コンソールのアプリケーション詳細ページに切り替えましょう。リダイレクト URI https://your-awesome-site.webflow.io/callback を追加し、「変更を保存」をクリックします。

Webflow デザイナーに戻り、ホームページに「サインイン」ボタンをドラッグアンドドロップし、後で getElementById() を使用して参照するために ID「sign-in」を割り当てます。

<script type="module">
  const signInButton = document.getElementById('sign-in');
  const onClickSignIn = () => logtoClient.signIn('https://your-awesome-site.webflow.io/callback');
  signInButton.addEventListener('click', onClickSignIn);
</script>

リダイレクトを処理する

もう少しで完了です！最後のステップでは、https://your-awesome-site.webflow.io/callback をリダイレクト URI として使用し、これを適切に処理する必要があります。

まず、Webflow で「Callback」ページを作成し、単に「Redirecting...」という静的なテキストを配置します。次に、以下のページレベルのカスタムコードを「Callback」ページに追加します。

<script type="module">
  (async () => {
    // SDK メソッドを呼び出してサインインコールバックロジックを処理する
    await logtoClient.handleSignInCallback(window.location.href);

    // 処理が完了したらホームページにリダイレクトする
    window.location.assign('https://your-awesome-site.webflow.io');
  })();
</script>

サインアウトの実装

.signOut() を呼び出すと、存在する場合、メモリと localStorage 内のすべての Logto データがクリアされます。

サインアウト後に、ユーザーをあなたのウェブサイトにリダイレクトするのは素晴らしいことです。Admin Console でポストサインアウト URI の 1 つとして https://your-awesome-site.webflow.io を追加し、.signOut() を呼び出す際に URL をパラメーターとして使用しましょう。

サインアウトボタンを実装する

Webflow デザイナーに戻り、ホームページに「サインアウト」ボタンを追加します。同様に、ボタンに ID「sign-out」を割り当て、ページレベルのカスタムコードに次のコードを追加します。

const signOutButton = document.getElementById('sign-out');
const onClickSignOut = () => logtoClient.signOut('https://your-awesome-site.webflow.io');
signOutButton.addEventListener('click', onClickSignOut);

認証 (Authentication) ステータスの処理

Logto SDK では、一般的に logtoClient.isAuthenticated() メソッドを使用して認証 (Authentication) ステータスを確認できます。ユーザーがサインインしている場合、この値は true になります。そうでない場合は false になります。

Webflow サイトでも、プログラムでサインインおよびサインアウトボタンを表示および非表示にするためにこれを使用できます。次のカスタムコードを適用して、ボタンの CSS を適切に調整してください。

const isAuthenticated = await logtoClient.isAuthenticated();

signInButton.style.display = isAuthenticated ? 'none' : 'block';
signOutButton.style.display = isAuthenticated ? 'block' : 'none';

チェックポイント: Webflow サイトをテストする

次に、サイトをテストします：

サイト URL をデプロイして訪問し、サインインボタンが表示されていることを確認します。
サインインボタンをクリックすると、SDK がサインインプロセスを開始し、Logto のサインインページにリダイレクトされます。
サインイン後、サイトに戻り、ユーザー名とサインアウトボタンが表示されます。
サインアウトボタンをクリックしてサインアウトします。

ユーザー情報の取得

これらの Logto メソッドを使用して、プログラムでユーザー情報を取得できます：

getIdTokenClaims: ローカルの ID トークンをデコードしてユーザー情報を取得します。いくつかのクレームは利用できない場合があります。
fetchUserInfo: userinfo エンドポイントにリクエストを送信してユーザー情報を取得します。

重要なのは、取得できるユーザー情報のクレームは、サインイン時にユーザーが使用したスコープに依存することです。パフォーマンスとデータサイズを考慮して、ID トークンにはすべてのユーザークレームが含まれていない場合があり、いくつかのユーザークレームは userinfo エンドポイントでのみ利用可能です（以下の関連リストを参照してください）。

Logto は OIDC のスコープとクレームの規約を使用して、ID トークンおよび OIDC userinfo エンドポイントからユーザー情報を取得するためのスコープとクレームを定義します。「スコープ」と「クレーム」は、OAuth 2.0 および OpenID Connect (OIDC) 仕様からの用語です。

要するに、スコープをリクエストすると、ユーザー情報の対応するクレームを取得できます。例えば、`email` スコープをリクエストすると、ユーザーの `email` と `email_verified` データを取得できます。

デフォルトでは、Logto SDK は常に 3 つのスコープをリクエストします：`openid`、`profile`、および `offline_access` です。これらのデフォルトスコープを削除する方法はありませんが、Logto を設定する際にさらにスコープを追加することができます：

<script type="module">
  // jsdelivr CDN から \`@logto/browser\` SDK をインポート
  import LogtoClient from 'https://esm.run/@logto/browser';

  // \`logtoClient\` インスタンスを window オブジェクトに割り当て、
  // 他のページでのグローバルな使用を可能にする
  window.logtoClient = new LogtoClient({
    endpoint: '<your-logto-endpoint>', // 例: http://localhost:3001
    appId: '<your-application-id>',
    scopes: [
      UserScope.Email,
      UserScope.Phone,
      UserScope.CustomData,
      UserScope.Identities,
      UserScope.Organizations,
    ],
  });
</script>

サポートされているスコープと対応するクレームのリストはこちらです：

openid

クレーム名	タイプ	説明	ユーザー情報が必要か？
sub	`string`	ユーザーの一意の識別子	いいえ

profile

クレーム名	タイプ	説明	ユーザー情報が必要か？
name	`string`	ユーザーのフルネーム	いいえ
username	`string`	ユーザーのユーザー名	いいえ
picture	`string`	エンドユーザーのプロフィール画像の URL。この URL は画像ファイル（例：PNG、JPEG、または GIF 画像ファイル）を参照する必要があります。画像を含む Web ページを参照してはいけません。この URL は、エンドユーザーを説明する際に表示するのに適したプロフィール写真を特に参照するべきであり、エンドユーザーが撮影した任意の写真を参照するべきではありません。	いいえ
created_at	`number`	エンドユーザーが作成された時間。時間は Unix エポック（1970-01-01T00:00:00Z）からのミリ秒数で表されます。	いいえ
updated_at	`number`	エンドユーザーの情報が最後に更新された時間。時間は Unix エポック（1970-01-01T00:00:00Z）からのミリ秒数で表されます。	いいえ

その他の標準クレームには、family_name、given_name、middle_name、nickname、preferred_username、profile、website、gender、birthdate、zoneinfo、および locale が含まれ、ユーザー情報エンドポイントを要求することなく profile スコープに含まれます。上記のクレームと比較しての違いは、これらのクレームは値が空でない場合にのみ返されることであり、上記のクレームは値が空の場合に null を返します。

注記:

標準クレームとは異なり、created_at と updated_at クレームは秒ではなくミリ秒を使用しています。

email

クレーム名	タイプ	説明	ユーザー情報が必要か？
email	`string`	ユーザーのメールアドレス	いいえ
email_verified	`boolean`	メールアドレスが確認済みかどうか	いいえ

phone

クレーム名	タイプ	説明	ユーザー情報が必要か？
phone_number	`string`	ユーザーの電話番号	いいえ
phone_number_verified	`boolean`	電話番号が確認済みかどうか	いいえ

address

住所クレームの詳細については、OpenID Connect Core 1.0 を参照してください。

custom_data

クレーム名	タイプ	説明	ユーザー情報が必要か？
custom_data	`object`	ユーザーのカスタムデータ	はい

identities

クレーム名	タイプ	説明	ユーザー情報が必要か？
identities	`object`	ユーザーのリンクされたアイデンティティ	はい
sso_identities	`array`	ユーザーのリンクされた SSO アイデンティティ	はい

roles

クレーム名	タイプ	説明	ユーザー情報が必要か？
roles	`string[]`	ユーザーのロール	いいえ

urn:logto:scope:organizations

クレーム名	タイプ	説明	ユーザー情報が必要か？
organizations	`string[]`	ユーザーが所属する組織の ID	いいえ
organization_data	`object[]`	ユーザーが所属する組織のデータ	はい

urn:logto:scope:organization_roles

クレーム名	タイプ	説明	ユーザー情報が必要か？
organization_roles	`string[]`	ユーザーが所属する組織のロール（`<organization_id>:<role_name>` の形式）	いいえ

パフォーマンスとデータサイズを考慮して、「ユーザー情報が必要か？」が「はい」の場合、クレームは ID トークンには表示されず、ユーザー情報エンドポイントのレスポンスで返されます。

API リソース

まず 🔐 ロールベースのアクセス制御 (RBAC) を読むことをお勧めします。これにより、Logto の RBAC の基本概念と API リソースを適切に設定する方法を理解できます。

Logto クライアントを設定する

API リソースを設定したら、アプリで Logto を設定する際にそれらを追加できます：

<script type="module">
  // jsdelivr CDN から \`@logto/browser\` SDK をインポート
  import LogtoClient from 'https://esm.run/@logto/browser';

  // \`logtoClient\` インスタンスを window オブジェクトに割り当て、
  // 他のページでのグローバル使用を可能にする
  window.logtoClient = new LogtoClient({
    endpoint: '<your-logto-endpoint>', // 例: http://localhost:3001
    appId: '<your-application-id>',
    resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'], // API リソースを追加
  });
</script>

各 API リソースには独自の権限 (スコープ) があります。

例えば、https://shopping.your-app.com/api リソースには shopping:read と shopping:write の権限があり、https://store.your-app.com/api リソースには store:read と store:write の権限があります。

これらの権限を要求するには、アプリで Logto を設定する際にそれらを追加できます：

<script type="module">
  // jsdelivr CDN から `@logto/browser` SDK をインポート
  import LogtoClient from 'https://esm.run/@logto/browser';

  window.logtoClient = new LogtoClient({
    endpoint: '<your-logto-endpoint>',
    appId: '<your-application-id>',
    scopes: ['shopping:read', 'shopping:write', 'store:read', 'store:write'],
    resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'],
  });
</script>

スコープが API リソースとは別に定義されていることに気付くかもしれません。これは、OAuth 2.0 のリソースインジケーターが、リクエストの最終的なスコープはすべてのターゲットサービスでのすべてのスコープの直積になると指定しているためです。

したがって、上記のケースでは、Logto での定義からスコープを簡略化できます。両方の API リソースは、プレフィックスなしで read と write スコープを持つことができます。その後、Logto の設定では：

<script type="module">
  // jsdelivr CDN から `@logto/browser` SDK をインポート
  import LogtoClient from 'https://esm.run/@logto/browser';

  window.logtoClient = new LogtoClient({
    endpoint: '<your-logto-endpoint>',
    appId: '<your-application-id>',
    scopes: ['read', 'write'],
    resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'],
  });
</script>

各 API リソースは、read と write の両方のスコープを要求します。

注記:

API リソースで定義されていないスコープを要求しても問題ありません。例えば、API リソースに email スコープが利用できなくても、email スコープを要求できます。利用できないスコープは安全に無視されます。

サインインが成功すると、Logto はユーザーのロールに応じて適切なスコープを API リソースに発行します。

API リソースのためのアクセストークンを取得する

特定の API リソースのアクセストークンを取得するには、getAccessToken メソッドを使用できます：

const isAuthenticated = await logtoClient.isAuthenticated();

if (isAuthenticated) {
  (async () => {
    const token = await logtoClient.getAccessToken();
    console.log(token);
  })();
}

このメソッドは、ユーザーが関連する権限を持っている場合に API リソースにアクセスするために使用できる JWT アクセストークンを返します。現在キャッシュされているアクセストークンが期限切れの場合、このメソッドは自動的にリフレッシュトークンを使用して新しいアクセストークンを取得しようとします。

組織トークンを取得する

組織 (Organization) が初めての場合は、🏢 組織 (マルチテナンシー) を読んで始めてください。

Logto クライアントを設定する際に、UserScope.Organizations スコープを追加する必要があります：

import LogtoClient, { UserScope } from 'https://esm.run/@logto/browser';

window.logtoClient = new LogtoClient({
  // ...other configs
  scopes: [UserScope.Organizations],
});

ユーザーがサインインしたら、ユーザーのための組織トークンを取得できます：

import { UserScope } from 'https://esm.run/@logto/browser';

const isAuthenticated = await logtoClient.isAuthenticated();

(async () => {
  if (!isAuthenticated) {
    return;
  }
  const claims = await logtoClient.getIdTokenClaims();

  console.log('ID トークンのクレーム:', claims);
  console.log('組織 ID:', claims.organizations);

  // 少なくとも 1 つの組織があると仮定して、最初のものを取得します
  const organizationId = claims.organizations[0];
  const token = await logtoClient.getOrganizationToken(organizationId);

  console.log('組織のアクセス トークン:', token);
})();

さらなる読み物

エンドユーザーフロー：認証 (Authentication) フロー、アカウントフロー、組織フローコネクターの設定認可 (Authorization)

前提条件​

統合​

Logto プロバイダーの初期化​

サインインの実装​

リダイレクトベースのサインインについて​

サインインリダイレクト URI を設定する​

サインインボタンを実装する​

リダイレクトを処理する​

サインアウトの実装​

サインアウトボタンを実装する​

認証 (Authentication) ステータスの処理​

チェックポイント: Webflow サイトをテストする​

ユーザー情報の取得​

API リソース​

Logto クライアントを設定する​

API リソースのためのアクセス トークンを取得する​

組織トークンを取得する​

さらなる読み物​