Integrate Logto with Capacitor JS

tip

• The following demonstration is built on Capacitor JS 5.0.6.

Prerequisites

• A Logto Cloud account or a self-hosted Logto (Check out the ⚡ Get started guide to create one if you don't have).
• A Logto native application created.

Installation

Install Logto SDK and peer dependencies via your favorite package manager:

npm

npm i @logto/capacitor
npm i @capacitor/browser @capacitor/app @capacitor/preferences

Yarn

yarn add @logto/capacitor
yarn add @capacitor/browser @capacitor/app @capacitor/preferences

pnpm

pnpm add @logto/capacitor
pnpm add @capacitor/browser @capacitor/app @capacitor/preferences

The @logto/capacitor package is the SDK for Logto. The remaining packages are its peer dependencies.

Integration

Init Logto client

Add the following code to your Capacitor project:

import LogtoClient, { type LogtoConfig } from '@logto/capacitor';

const logtoConfig: LogtoConfig = {
  endpoint: '<your-logto-endpoint>',
  appId: '<your-application-id>',
};

const logtoClient = new LogtoClient(config);

Implement sign-in

Before we dive into the details, here's a quick overview of the end-user experience. The sign-in process can be simplified as follows:

1. Your app invokes the sign-in method.
2. The user is redirected to the Logto sign-in page. For native apps, the system browser is opened.
3. The user signs in and is redirected back to your app (configured as the redirect URI).

Regarding redirect-based sign-in

1. This authentication process follows the OpenID Connect (OIDC) protocol, and Logto enforces strict security measures to protect user sign-in.
2. If you have multiple apps, you can use the same identity provider (Logto). Once the user signs in to one app, Logto will automatically complete the sign-in process when the user accesses another app.

To learn more about the rationale and benefits of redirect-based sign-in, see Logto sign-in experience explained.

---

Now, let's configure the redirect URI. The redirect URI is used to redirect the user back to your application after the authentication flow.

Ensure that the URI redirects to the Capacitor app, for example, com.example.app://callback. The value may vary depending on your Capacitor app configuration. For more details, see Capacitor Deep Links.

Then, add the following code to the onClick handler of the sign-in button:

const onClick = async () => {
  await logtoClient.signIn('com.example.app://callback');
  console.log(await logtoClient.isAuthenticated()); // true
  console.log(await logtoClient.getIdTokenClaims()); // { sub: '...', ... }
};

Implement sign-out

Since Capacitor leverages the Safari View Controller on iOS and Chrome Custom Tabs on Android, the authentication state can be persisted for a while. However, sometimes the user may want to sign out of the application immediately. In this case, we can use the signOut method to sign out the user:

const onClick = async () => {
  await logtoClient.signOut();
  console.log(await logtoClient.isAuthenticated()); // false
};

The signOut method has an optional parameter for the post sign-out redirect URI. If it's not provided, the user will be redirected to the Logto sign-out page.

The user needs to click "Done" to close the web view and return to the Capacitor app. If you want to automatically redirect the user back to the Capacitor app, you can provide the post sign-out redirect URI, for instance, com.example.app://callback/sign-out.

Ensure that the post sign-out redirect URI can redirect to the Capacitor app. Then add the following code to the onClick handler of the sign-out button:

const onClick = async () => {
  await logtoClient.signOut('com.example.app://callback/sign-out');
};

Checkpoint: Trigger the authentication flow

Run the Capacitor app and click the sign-in button. A browser window will open, redirecting to the Logto sign-in page.

If the user closes the browser window without completing the authentication flow, the Capacitor app will receive a LogtoClientError.

Get user information

Display user information

To display the user's information, you can use the getIdTokenClaims() method. For example, in a Capacitor app:

const userClaims = await logtoClient.getIdTokenClaims();
console.log(userClaims);

Request additional claims

You may find some user information are missing in the returned object from client.getIdTokenClaims(). This is because OAuth 2.0 and OpenID Connect (OIDC) are designed to follow the principle of least privilege (PoLP), and Logto is built on top of these standards.

By default, limited claims are returned. If you need more information, you can request additional scopes to access more claims.

info

A "claim" is an assertion made about a subject; a "scope" is a group of claims. In the current case, a claim is a piece of information about the user.

Here's a non-normative example the scope - claim relationship:

tip

The "sub" claim means "subject", which is the unique identifier of the user (i.e. user ID).

Logto SDK will always request three scopes: openid, profile, and offline_access.

To request additional scopes, you can pass the scopes to the LogtoConfig object when initializing the client. For example:

const logtoConfig = {
  scopes: ['email', 'phone', 'custom_data', 'organizations'],
};

Then you can access the additional claims in the return value of client.getIdTokenClaims():

Claims that need network requests

To prevent bloating the ID token, some claims require network requests to fetch. For example, the custom_data claim is not included in the user object even if it's requested in the scopes. To access these claims, you can use the client.fetchUserInfo() method:

const userInfo = await logtoClient.fetchUserInfo();
console.log(userInfo);

This method will fetch the user information by requesting to the userinfo endpoint. To learn more about the available scopes and claims, see the Scopes and claims section.

Scopes and claims

Logto uses OIDC scopes and claims conventions to define the scopes and claims for retrieving user information from the ID token and OIDC userinfo endpoint. Both of the "scope" and the "claim" are terms from the OAuth 2.0 and OpenID Connect (OIDC) specifications.

In short, when you request a scope, you will get the corresponding claims in the user information. For example, if you request the `email` scope, you will get the `email` and `email_verified` data of the user.

By default, Logto SDK will always request three scopes: `openid`, `profile`. And `offline_access`, and there is no way to remove these default scopes. But you can add more scopes when configuring Logto:

import { type LogtoConfig, UserScope } from '@logto/capacitor';

const config: LogtoConfig = {
  // ...other options
  scopes: [UserScope.Email, UserScope.Phone], // Add the scopes you need
};

Here's the list of supported scopes and the corresponding claims:

openid

Claim name	Type	Description	Needs userinfo?
sub	string	The unique identifier of the user	No

profile

Claim name	Type	Description	Needs userinfo?
name	string	The full name of the user	No
username	string	The username of the user	No
picture	string	URL of the End-User's profile picture. This URL MUST refer to an image file (for example, a PNG, JPEG, or GIF image file), rather than to a Web page containing an image. Note that this URL SHOULD specifically reference a profile photo of the End-User suitable for displaying when describing the End-User, rather than an arbitrary photo taken by the End-User.	No
created_at	number	Time the End-User was created. The time is represented as the number of milliseconds since the Unix epoch (1970-01-01T00:00:00Z).	No
updated_at	number	Time the End-User's information was last updated. The time is represented as the number of milliseconds since the Unix epoch (1970-01-01T00:00:00Z).	No

Other standard claims include family_name, given_name, middle_name, nickname, preferred_username, profile, website, gender, birthdate, zoneinfo, and locale will be also included in the profile scope without the need for requesting the userinfo endpoint. A difference compared to the claims above is that these claims will only be returned when their values are not empty, while the claims above will return null if the values are empty.

note

Unlike the standard claims, the created_at and updated_at claims are using milliseconds instead of seconds.

email

Claim name	Type	Description	Needs userinfo?
email	string	The email address of the user	No
email_verified	boolean	Whether the email address has been verified	No

phone

Claim name	Type	Description	Needs userinfo?
phone_number	string	The phone number of the user	No
phone_number_verified	boolean	Whether the phone number has been verified	No

address

Please refer to the OpenID Connect Core 1.0 for the details of the address claim.

custom_data

Claim name	Type	Description	Needs userinfo?
custom_data	object	The custom data of the user	Yes

identities

Claim name	Type	Description	Needs userinfo?
identities	object	The linked identities of the user	Yes
sso_identities	array	The linked SSO identities of the user	Yes

urn:logto:scope:organizations

Claim name	Type	Description	Needs userinfo?
organizations	string[]	The organization IDs the user belongs to	No
organization_data	object[]	The organization data the user belongs to	Yes

urn:logto:scope:organization_roles

Claim name	Type	Description	Needs userinfo?
organization_roles	string[]	The organization roles the user belongs to with the format of <organization_id>:<role_name>	No

---

Considering performance and the data size, if "Needs userinfo?" is "Yes", it means the claim will not show up in the ID token, but will be returned in the userinfo endpoint response.

API resources and organizations

We recommend to read 🔐 Role-Based Access Control (RBAC) first to understand the basic concepts of Logto RBAC and how to set up API resources properly.

Configure Logto client

Once you have set up the API resources, you can add them when configuring Logto in your app:

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'], // Add API resources
};

Each API resource has its own permissions (scopes).

For example, the https://shopping.your-app.com/api resource has the shopping:read and shopping:write permissions, and the https://store.your-app.com/api resource has the store:read and store:write permissions.

To request these permissions, you can add them when configuring Logto in your app:

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'],
};

You may notice that scopes are defined separately from API resources. This is because Resource Indicators for OAuth 2.0 specifies the final scopes for the request will be the cartesian product of all the scopes at all the target services.

Thus, in the above case, scopes can be simplified from the definition in Logto, both of the API resources can have read and write scopes without the prefix. Then, in the Logto config:

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'],
};

For every API resource, it will request for both read and write scopes.

note

It is fine to request scopes that are not defined in the API resources. For example, you can request the email scope even if the API resources don't have the email scope available. Unavailable scopes will be safely ignored.

After the successful sign-in, Logto will issue proper scopes to API resources according to the user's roles.

Fetch access token for the API resource

To fetch the access token for a specific API resource, you can use the getAccessToken method:

const token = await logtoClient.getAccessToken('https://shopping.your-app.com/api');

This method will return a JWT access token that can be used to access the API resource when the user has related permissions. If the current cached access token has expired, this method will automatically try to use a refresh token to get a new access token.

Fetch organization tokens

If organization is new to you, please read 🏢 Organizations (Multi-tenancy) to get started.

You need to add UserScope.Organizations scope when configuring the Logto client:

import { type LogtoConfig, UserScope } from '@logto/capacitor';

const config: LogtoConfig = {
  // ...other configs
  scopes: [UserScope.Organizations],
};

Once the user is signed in, you can fetch the organization token for the user:

await logtoClient.getOrganizationToken(organizationId);

Further readings

• Customize sign-in experience
• Configure connectors
• Protect your API