あなたの Expo (React Native) アプリケーションに認証 (Authentication) を追加する
- 次のデモンストレーションは Expo ~50.0.6 上で構築されています。
- サンプルプロジェクトは、私たちの SDK リポジトリ で利用可能です。
前提条件
- Logto Cloud アカウントまたは セルフホスト Logto。
- Logto ネイティブアプリケーションが作成されていること。
インストール
お気に入りのパッケージマネージャーを使用して Logto SDK とピア依存関係をインストールします:
- npm
- Yarn
- pnpm
npm i @logto/rn
npm i expo-crypto expo-secure-store expo-web-browser @react-native-async-storage/async-storage
yarn add @logto/rn
yarn add expo-crypto expo-secure-store expo-web-browser @react-native-async-storage/async-storage
pnpm add @logto/rn
pnpm add expo-crypto expo-secure-store expo-web-browser @react-native-async-storage/async-storage
@logto/rn
パッケージは Logto の SDK です。残りのパッケージはそのピア依存関係です。これらは直接の依存関係としてリストされることができませんでした。なぜなら、Expo CLI はネイティブモジュールのすべての依存関係がルートプロジェクトの package.json
に直接インストールされることを要求するからです。
ベア React Native アプリ にこれをインストールする場合は、これらの 追加のインストール手順 に従う必要があります。
統合
Logto プロバイダーを初期化する
LogtoProvider
をインポートして使用し、Logto コンテキストを提供します:
import { LogtoProvider, LogtoConfig } from '@logto/rn';
const config: LogtoConfig = {
endpoint: '<your-logto-endpoint>',
appId: '<your-application-id>',
};
const App = () => (
<LogtoProvider config={config}>
<YourAppContent />
</LogtoProvider>
);
サインインとサインアウトを実装する
詳細に入る前に、エンドユーザーの体験について簡単に説明します。サインインプロセスは次のように簡略化できます:
- あなたのアプリがサインインメソッドを呼び出します。
- ユーザーは Logto のサインインページにリダイレクトされます。ネイティブアプリの場合、システムブラウザが開かれます。
- ユーザーがサインインし、あなたのアプリにリダイレクトされます(リダイレクト URI として設定されています)。
リダイレクトベースのサインインについて
- この認証 (Authentication) プロセスは OpenID Connect (OIDC) プロトコルに従い、Logto はユーザーのサインインを保護するために厳格なセキュリティ対策を講じています。
- 複数のアプリがある場合、同じアイデンティティプロバイダー (Logto) を使用できます。ユーザーがあるアプリにサインインすると、Logto は別のアプリにアクセスした際に自動的にサインインプロセスを完了します。
リダイレクトベースのサインインの理論と利点について詳しく知るには、Logto サインイン体験の説明を参照してください。
Logto Console のアプリケーション詳細ページに移動します。ネイティブリダイレクト URI(例:io.logto://callback
)を追加し、「保存」をクリックします。
-
iOS の場合、
ASWebAuthenticationSession
クラスがリダイレクト URI を登録されているかどうかに関係なくリッスンするため、リダイレクト URI スキームは実際には重要ではありません。 -
Android の場合、リダイレクト URI スキームは Expo の
app.json
ファイルに記入する必要があります。例えば:app.json{
"expo": {
"scheme": "io.logto"
}
}
さて、アプリに戻って、useLogto
フックを使用してサインインとサインアウトを行うことができます:
import { useLogto } from '@logto/rn';
import { Button } from 'react-native';
const Content = () => {
const { signIn, signOut, isAuthenticated } = useLogto();
return (
<div>
{isAuthenticated ? (
<Button title="Sign out" onPress={async () => signOut()} />
) : (
// リダイレクト URI を自分のものに置き換えてください
<Button title="Sign in" onPress={async () => signIn('io.logto://callback')} />
)}
</div>
);
};
チェックポイント: アプリケーションをテストする
これで、アプリケーションをテストできます:
- アプリケーションを実行すると、サインインボタンが表示されます。
- サインインボタンをクリックすると、SDK がサインインプロセスを初期化し、Logto のサインインページにリダイレクトされます。
- サインインすると、アプリケーションに戻り、サインアウトボタンが表示されます。
- サインアウトボタンをクリックしてローカルストレージをクリアし、サインアウトします。
ユーザー情報を取得する
ユーザー情報を表示する
ユーザーの情報を表示するには、getIdTokenClaims()
メソッドを使用できます:
import { useLogto } from '@logto/rn';
import { Button, Text } from 'react-native';
const Content = () => {
const { getIdTokenClaims, isAuthenticated } = useLogto();
const [user, setUser] = useState(null);
useEffect(() => {
if (isAuthenticated) {
getIdTokenClaims().then((claims) => {
setUser(claims);
});
}
}, [isAuthenticated]);
return (
<div>
{isAuthenticated ? (
<>
<Text>{user?.name}</Text>
<Text>{user?.email}</Text>
<Button title="Sign out" onPress={async () => signOut()} />
</>
) : (
<Button title="Sign in" onPress={async () => signIn('io.logto://callback')} />
)}
</div>
);
};
追加のクレーム (Claims) をリクエストする
getIdTokenClaims()
から返されるオブジェクトに一部のユーザー情報が欠けていることがあります。これは、OAuth
2.0 と OpenID Connect (OIDC) が最小特権の原則 (PoLP) に従うように設計されており、Logto
はこれらの標準に基づいて構築されているためです。
デフォルトでは、限られたクレーム (Claim) が返されます。より多くの情報が必要な場合は、追加のスコープ (Scope) をリクエストして、より多くのクレーム (Claim) にアクセスできます。
「クレーム (Claim)」はサブジェクトについての主張であり、「スコープ (Scope)」はクレーム (Claim) のグループです。現在のケースでは、クレーム (Claim) はユーザーに関する情報の一部です。
スコープ - クレーム (Claim) 関係の非規範的な例を示します:
「sub」クレーム (Claim) は「サブジェクト (Subject)」を意味し、ユーザーの一意の識別子(つまり、ユーザー ID)です。
Logto SDK は常に 3 つのスコープ (Scope) をリクエストします:openid
、profile
、および offline_access
。
追加のスコープをリクエストするには、スコープを LogtoConfig
オブジェクトに渡すことができます:
import { LogtoProvider, LogtoConfig, UserScope } from '@logto/rn';
const config: LogtoConfig = {
appId: '<your-application-id>',
endpoint: '<your-logto-endpoint>',
scopes: [
UserScope.Email,
UserScope.Phone,
UserScope.CustomData,
UserScope.Identities,
UserScope.Organizations,
],
};
const App = () => <LogtoProvider config={config}>{/* Your app content */}</LogtoProvider>;
ネットワークリクエストが必要なクレーム (Claims)
ID トークンの肥大化を防ぐために、一部のクレーム (Claims) は取得するためにネットワークリクエストが必要です。例えば、custom_data
クレームはスコープで要求されてもユーザーオブジェクトに含まれません。これらのクレームにアクセスするには、 fetchUserInfo()
メソッドを使用できます:
import { useLogto } from '@logto/rn';
import { Button, Text } from 'react-native';
const Content = () => {
const { fetchUserInfo, isAuthenticated } = useLogto();
const [user, setUser] = useState(null);
useEffect(() => {
if (isAuthenticated) {
fetchUserInfo().then((userInfo) => {
setUser(userInfo);
});
}
}, [isAuthenticated]);
return (
<div>
{isAuthenticated ? (
<>
<Text>{user?.name}</Text>
<Text>{user?.email}</Text>
<Button title="Sign out" onPress={async () => signOut()} />
</>
) : (
<Button title="Sign in" onPress={async () => signIn('io.logto://callback')} />
)}
</div>
);
};
スコープとクレーム (Claims)
Logto は OIDC の スコープとクレームの規約 を使用して、ID トークンおよび OIDC userinfo エンドポイント からユーザー情報を取得するためのスコープとクレームを定義します。「スコープ」と「クレーム」は、OAuth 2.0 および OpenID Connect (OIDC) 仕様からの用語です。
サポートされているスコープと対応するクレーム (Claims) のリストはこちらです:
openid
クレーム名 | タイプ | 説明 | ユーザー情報が必要か? |
---|---|---|---|
sub | string | ユーザーの一意の識別子 | いいえ |
profile
クレーム名 | タイプ | 説明 | ユーザー情報が必要か? |
---|---|---|---|
name | string | ユーザーのフルネーム | いいえ |
username | string | ユーザーのユーザー名 | いいえ |
picture | string | エンドユーザーのプロフィール写真の URL。この URL は、画像を含む Web ページではなく、画像ファイル(例えば PNG、JPEG、または GIF 画像ファイル)を指す必要があります。この 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
クレーム名 | タイプ | 説明 | ユーザー情報が必要か? |
---|---|---|---|
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 アイデンティティ | はい |
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 を設定する際にそれらを追加できます:
import { LogtoConfig } from '@logto/rn';
const config: LogtoConfig = {
appId: '<your-application-id>',
endpoint: '<your-logto-endpoint>',
// API リソースを追加
resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'],
};
各 API リソースには独自の権限 (スコープ) があります。
例えば、https://shopping.your-app.com/api
リソースには shopping:read
と shopping:write
の権限があり、https://store.your-app.com/api
リソースには store:read
と store:write
の権限があります。
これらの権限を要求するには、アプリで Logto を設定する際にそれらを追加できます:
import { LogtoConfig } from '@logto/rn';
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 { LogtoConfig } from '@logto/rn';
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
メソッドを使用できます:
import { useLogto } from '@logto/rn';
const AccessToken = () => {
const { isAuthenticated, getAccessToken } = useLogto();
const [accessToken, setAccessToken] = useState('');
useEffect(() => {
(async () => {
if (isAuthenticated) {
const token = await getAccessToken('https://shopping.your-app.com/api');
setAccessToken(token);
}
})();
}, [isAuthenticated, getAccessToken]);
return <p>{{ accessToken }}</p>;
};
このメソッドは、ユーザーが関連する権限を持っている場合に API リソースにアクセスするために使用できる JWT アクセス トークンを返します。現在キャッシュされているアクセス トークンが期限切れの場合、このメソッドは自動的にリフレッシュ トークンを使用して新しいアクセス トークンを取得しようとします。
ユーザーの組織トークンを取得する
組織 (Organization) が初めての場合は、🏢 組織 (マルチテナンシー) を読んで始めてください。
Logto クライアントを設定する際に、UserScope.Organizations
スコープを追加する必要があります:
import { LogtoConfig, UserScope } from '@logto/rn';
const config: LogtoConfig = {
// ...other configs
scopes: [UserScope.Organizations],
};
ユーザーがサインインしたら、ユーザーのための組織トークンを取得できます:
import { useLogto } from '@logto/rn';
import { useEffect, useState } from 'react';
const Organizations = () => {
const { isAuthenticated, getOrganizationToken, getIdTokenClaims } = useLogto();
const [organizationIds, setOrganizationIds] = useState<string[]>();
useEffect(() => {
(async () => {
if (!isAuthenticated) {
return;
}
const claims = await getIdTokenClaims();
console.log('ID トークン クレーム', claims);
setOrganizationIds(claims?.organizations);
})();
}, [isAuthenticated, getIdTokenClaims]);
return (
<section>
<ul>
{organizationIds?.map((organizationId) => {
return (
<li key={organizationId}>
<span>{organizationId}</span>
<button
type="button"
onClick={async () => {
console.log('raw token', await getOrganizationToken(organizationId));
}}
>
トークンを取得 (コンソールを参照)
</button>
</li>
);
})}
</ul>
</section>
);
};
export default Organizations;
トラブルシューティング
@logto/client/shim
を解決できない
Expo プロジェクトで Unable to resolve "@logto/client/shim" from "node_modules/@logto/rn/lib/index.js"
というエラーが発生した場合、次の内容を metro.config.js
ファイルに追加することで解決できます:
const config = {
// ...
resolver: {
unstable_enablePackageExports: true,
},
};
module.exports = config;
このエラーは、@logto/rn
パッケージが @logto/client/shim
モジュールを解決できないことを示しています。
@logto/client
パッケージでノードエクスポートが使用されており、Metro バンドラーではパッケージエクスポートがデフォルトで有効になっていないため、手動で有効にする必要があります。
詳細については、React Native パッケージエクスポートサポート を参照してください。