Capacitor JS アプリケーションへ認証機能の追加
- 次のデモンストレーションは、Capacitor JS 5.0.6 に基づいています。
前提条件
- Logto Cloud アカウントまたは セルフホスト Logto。
- Logto ネイティブアプリケーションが作成されていること。
インストール
お気に入りのパッケージマネージャーを使用して Logto SDK とピア依存関係をインストールします:
- npm
- Yarn
- pnpm
npm i @logto/capacitor
npm i @capacitor/browser @capacitor/app @capacitor/preferences
yarn add @logto/capacitor
yarn add @capacitor/browser @capacitor/app @capacitor/preferences
pnpm add @logto/capacitor
pnpm add @capacitor/browser @capacitor/app @capacitor/preferences
@logto/capacitor パッケージは Logto の SDK です。残りのパッケージはそのピア依存関係です。
統合
Logto クライアントの初期化
次のコードを Capacitor プロジェクトに追加します:
import LogtoClient, { type LogtoConfig } from '@logto/capacitor';
const logtoConfig: LogtoConfig = {
endpoint: '<your-logto-endpoint>',
appId: '<your-application-id>',
};
const logtoClient = new LogtoClient(config);
サインインの実装
詳細に入る前に、エンドユーザー体験の概要を簡単にご紹介します。サインインプロセスは次のようにシンプルにまとめられます:
- アプリがサインインメソッドを呼び出します。
- ユーザーは Logto のサインインページにリダイレクトされます。ネイティブアプリの場合は、システムブラウザが開かれます。
- ユーザーがサインインし、アプリ(リダイレクト URI として設定)に戻されます。
リダイレクトベースのサインインについて
- この認証 (Authentication) プロセスは OpenID Connect (OIDC) プロトコルに従い、Logto はユーザーのサインインを保護するために厳格なセキュリティ対策を講じています。
- 複数のアプリがある場合、同じアイデンティティプロバイダー (Logto) を使用できます。ユーザーがあるアプリにサインインすると、Logto は別のアプリにアクセスした際に自動的にサインインプロセスを完了します。
リダイレクトベースのサインインの理論と利点について詳しく知るには、Logto サインイン体験の説明を参照してください。
次に、リダイレクト URI を設定しましょう。リダイレクト URI は、認証 (Authentication) フローの後にユーザーをアプリケーションに戻すために使用されます。
URI が Capacitor アプリにリダイレクトすることを確認してください。例えば、com.example.app://callback のようにします。この値は、Capacitor アプリの設定によって異なる場合があります。詳細については、Capacitor Deep Links を参照してください。
次に、サインインボタンの onClick ハンドラーに次のコードを追加します:
const onClick = async () => {
await logtoClient.signIn('com.example.app://callback');
console.log(await logtoClient.isAuthenticated()); // true
console.log(await logtoClient.getIdTokenClaims()); // { sub: '...', ... }
};
サインアウトの実装
Capacitor は iOS では Safari View Controller、Android では Chrome Custom Tabs を利用しているため、認証 (Authentication) 状態はしばらく保持されることがあります。しかし、ユーザーがすぐにアプリケーションからサインアウトしたい場合もあります。この場合、signOut メソッドを使用してユーザーをサインアウトできます:
const onClick = async () => {
await logtoClient.signOut();
console.log(await logtoClient.isAuthenticated()); // false
};
signOut メソッドには、サインアウト後のリダイレクト URI のオプションパラメータがあります。指定されていない場合、ユーザーは Logto のサインアウトページにリダイレクトされます。
ユーザーは「完了」をクリックしてウェブビューを閉じ、Capacitor アプリに戻る必要があります。ユーザーを自動的に Capacitor アプリに戻したい場合は、サインアウト後のリダイレクト URI を指定できます。例えば、com.example.app://callback/sign-out のようにします。
サインアウト後のリダイレクト URI が Capacitor アプリにリダイレクトできることを確認してください。次に、サインアウトボタンの onClick ハンドラーに次のコードを追加します:
const onClick = async () => {
await logtoClient.signOut('com.example.app://callback/sign-out');
};
チェックポイント: 認証 (Authentication) フローをトリガーする
Capacitor アプリを実行し、サインインボタンをクリックします。ブラウザウィンドウが開き、Logto のサインインページにリダイレクトされます。
ユーザーが認証 (Authentication) フローを完了せずにブラウザウィンドウを閉じた場合、Capacitor アプリは LogtoClientError を受け取ります。
ユーザー情報の取得
ユーザー情報の表示
ユーザーの情報を表示するには、getIdTokenClaims() メソッドを使用できます。例えば、Capacitor アプリで:
const userClaims = await logtoClient.getIdTokenClaims();
console.log(userClaims);
追加のクレーム (Claims) のリクエスト
client.getIdTokenClaims() から返されるオブジェクトに一部のユーザー情報が欠けていることがあります。これは、OAuth
2.0 と OpenID Connect (OIDC) が最小特権の原則 (PoLP) に従うように設計されており、Logto
はこれらの標準に基づいて構築されているためです。
デフォルトでは、限られたクレーム (Claims) が返されます。より多くの情報が必要な場合は、追加のスコープ (Scopes) をリクエストして、より多くのクレーム (Claims) にアクセスできます。
「クレーム (Claim)」はサブジェクトについての主張であり、「スコープ (Scope)」はクレーム (Claims) のグループです。現在のケースでは、クレーム (Claim) はユーザーに関する情報の一部です。
スコープ (Scope) とクレーム (Claim) の関係の非規範的な例を示します:
「sub」クレーム (Claim) は「サブジェクト (Subject)」を意味し、ユーザーの一意の識別子(つまり、ユーザー ID)です。
Logto SDK は常に 3 つのスコープ (Scopes) をリクエストします:openid、profile、および offline_access。
追加のスコープ (Scopes) をリクエストするには、クライアントを初期化する際に LogtoConfig オブジェクトにスコープ (Scopes) を渡すことができます。例えば:
const logtoConfig = {
scopes: ['email', 'phone', 'custom_data', 'organizations'],
};
その後、client.getIdTokenClaims() の戻り値で追加のクレーム (Claims) にアクセスできます:
ネットワークリクエストが必要なクレーム (Claims)
ID トークンの肥大化を防ぐために、一部のクレーム (Claims) は取得するためにネットワークリクエストが必要です。例えば、custom_data クレームはスコープで要求されてもユーザーオブジェクトに含まれません。これらのクレームにアクセスするには、 client.fetchUserInfo() メソッドを使用できます:
const userInfo = await logtoClient.fetchUserInfo();
console.log(userInfo);
スコープ (Scopes) とクレーム (Claims)
Logto は OIDC の スコープ (Scope) とクレーム (Claim) の規約 を使用して、ID トークンおよび OIDC userinfo エンドポイント からユーザー情報を取得するためのスコープ (Scope) とクレーム (Claim) を定義しています。「スコープ (Scope)」と「クレーム (Claim)」は、OAuth 2.0 および OpenID Connect (OIDC) 仕様の用語です。
標準の OIDC クレーム (Claim) については、ID トークンへの含有はリクエストされたスコープ (Scope) によって厳密に決定されます。拡張クレーム (Claim)(例:custom_data や organizations)は、カスタム ID トークン 設定を通じて ID トークンに追加で表示するように構成できます。
要するに、スコープ (Scope) をリクエストすると、対応するクレーム (Claim) がユーザー情報として取得できます。たとえば、`email` スコープ (Scope) をリクエストすると、ユーザーの `email` および `email_verified` データが取得できます。
デフォルトで、Logto SDK は常に 3 つのスコープ (Scope) をリクエストします:`openid`、`profile`、および `offline_access`。 これらのデフォルトスコープ (Scope) を削除する方法はありませんが、Logto の設定時に追加のスコープ (Scope) を追加できます:
import { type LogtoConfig, UserScope } from '@logto/capacitor';
const config: LogtoConfig = {
// ...other options
scopes: [UserScope.Email, UserScope.Phone], // 必要なスコープを追加します
};
こちらはサポートされているスコープと対応するクレーム (Claims) の一覧です:
標準 OIDC スコープ
openid(デフォルト)
| Claim name | Type | 説明 |
|---|---|---|
| sub | string | ユーザーの一意の識別子 |
profile(デフォルト)
| Claim name | Type | 説明 |
|---|---|---|
| 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)からのミリ秒数で表されます。 |
その他の 標準クレーム (Standard Claims) には、family_name、given_name、middle_name、nickname、preferred_username、profile、website、gender、birthdate、zoneinfo、locale などがあり、これらも profile スコープに含まれます(userinfo エンドポイントをリクエストする必要はありません)。上記のクレームとの違いは、これらのクレームは値が空でない場合のみ返される点です。一方、上記のクレームは値が空の場合 null が返されます。
標準クレーム (Standard Claims) とは異なり、created_at および updated_at クレームは秒ではなくミリ秒を使用しています。
email
| Claim name | Type | 説明 |
|---|---|---|
string | ユーザーのメールアドレス | |
| email_verified | boolean | メールアドレスが認証済みかどうか |
phone
| Claim name | Type | 説明 |
|---|---|---|
| phone_number | string | ユーザーの電話番号 |
| phone_number_verified | boolean | 電話番号が認証済みかどうか |
address
アドレスクレームの詳細については OpenID Connect Core 1.0 を参照してください。
(デフォルト) と記載されたスコープは常に Logto SDK によってリクエストされます。標準 OIDC スコープ下のクレーム (Claims) は、対応するスコープがリクエストされた場合、常に ID トークン (ID token) に含まれます — 無効化できません。
拡張スコープ
以下のスコープは Logto によって拡張されており、userinfo エンドポイント を通じてクレーム (Claims) を返します。これらのクレームは Console > Custom JWT を通じて ID トークン (ID token) に直接含めるよう設定することもできます。詳細は カスタム ID トークン を参照してください。
custom_data
| Claim name | Type | 説明 | デフォルトで ID トークンに含まれるか |
|---|---|---|---|
| custom_data | object | ユーザーのカスタムデータ |
identities
| Claim name | Type | 説明 | デフォルトで ID トークンに含まれるか |
|---|---|---|---|
| identities | object | ユーザーのリンク済みアイデンティティ | |
| sso_identities | array | ユーザーのリンク済み SSO アイデンティティ |
roles
| Claim name | Type | 説明 | デフォルトで ID トークンに含まれるか |
|---|---|---|---|
| roles | string[] | ユーザーのロール | ✅ |
urn:logto:scope:organizations
| Claim name | Type | 説明 | デフォルトで ID トークンに含まれるか |
|---|---|---|---|
| organizations | string[] | ユーザーが所属する組織 ID | ✅ |
| organization_data | object[] | ユーザーが所属する組織データ |
これらの組織クレーム (Organization Claims) は、不透明トークン (Opaque token) を使用している場合でも userinfo エンドポイント経由で取得できます。ただし、不透明トークン (Opaque token) は組織トークン (Organization token) として組織固有リソースへのアクセスには使用できません。詳細は 不透明トークン (Opaque token) と組織 (Organizations) を参照してください。
urn:logto:scope:organization_roles
| Claim name | Type | 説明 | デフォルトで ID トークンに含まれるか |
|---|---|---|---|
| organization_roles | string[] | ユーザーが所属する組織ロール(<organization_id>:<role_name> 形式) | ✅ |
API リソースと組織
まず 🔐 ロールベースのアクセス制御 (RBAC) を読むことをお勧めします。これにより、Logto の RBAC の基本概念と API リソースを適切に設定する方法を理解できます。
Logto クライアントを設定する
API リソースを設定したら、アプリで Logto を設定する際にそれらを追加できます:
import { type LogtoConfig } from '@logto/capacitor';
const config: LogtoConfig = {
appId: '<your-application-id>',
endpoint: '<your-logto-endpoint>',
resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'], // API リソースを追加
};
各 API リソースには独自の権限 (スコープ) があります。
例えば、https://shopping.your-app.com/api リソースには shopping:read と shopping:write の権限があり、https://store.your-app.com/api リソースには store:read と store:write の権限があります。
これらの権限を要求するには、アプリで Logto を設定する際にそれらを追加できます:
import { type LogtoConfig } from '@logto/capacitor';
const config: LogtoConfig = {
appId: '<your-application-id>',
endpoint: '<your-logto-endpoint>',
scopes: ['shopping:read', 'shopping:write', 'store:read', 'store:write'],
resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'],
};
スコープが API リソースとは別に定義されていることに気付くかもしれません。これは、OAuth 2.0 のリソースインジケーター が、リクエストの最終的なスコープはすべてのターゲットサービスでのすべてのスコープの直積になると指定しているためです。
したがって、上記のケースでは、Logto での定義からスコープを簡略化できます。両方の API リソースは、プレフィックスなしで read と write スコープを持つことができます。その後、Logto の設定では:
import { type LogtoConfig } from '@logto/capacitor';
const config: LogtoConfig = {
appId: '<your-application-id>',
endpoint: '<your-logto-endpoint>',
scopes: ['read', 'write'],
resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'],
};
各 API リソースは、read と write の両方のスコープを要求します。
API リソースで定義されていないスコープを要求しても問題ありません。例えば、API リソースに email スコープが利用できなくても、email スコープを要求できます。利用できないスコープは安全に無視されます。
サインインが成功すると、Logto はユーザーのロールに応じて適切なスコープを API リソースに発行します。
API リソースのためのアクセス トークンを取得する
特定の API リソースのアクセス トークンを取得するには、getAccessToken メソッドを使用できます:
const token = await logtoClient.getAccessToken('https://shopping.your-app.com/api');
このメソッドは、ユーザーが関連する権限を持っている場合に API リソースにアクセスするために使用できる JWT アクセス トークンを返します。現在キャッシュされているアクセス トークンが期限切れの場合、このメソッドは自動的にリフレッシュ トークンを使用して新しいアクセス トークンを取得しようとします。
組織トークンを取得する
組織 (Organization) が初めての場合は、🏢 組織 (マルチテナンシー) を読んで始めてください。
Logto クライアントを設定する際に、UserScope.Organizations スコープを追加する必要があります:
import { type LogtoConfig, UserScope } from '@logto/capacitor';
const config: LogtoConfig = {
// ...other configs
scopes: [UserScope.Organizations],
};
ユーザーがサインインしたら、ユーザーのための組織トークンを取得できます:
await logtoClient.getOrganizationToken(organizationId);