> ## Documentation Index
> Fetch the complete documentation index at: https://docs.moca.network/llms.txt
> Use this file to discover all available pages before exploring further.

# User Login & Sessions

> AIR Kit user login and session management — built-in authentication with single sign-on across the Moca ecosystem, or bring your own auth via Partner JWT.

## Using AIR Kit as your authentication provider

By default, we provide the following methods for users:

* Google Login
* Passwordless Email Login
* Wallet Login (EOA wallet support)

<Tabs>
  <Tab title="Web">
    ```tsx theme={null}
    login(options?: { authToken?: string }): Promise<AirLoginResult>
    ```
  </Tab>

  <Tab title="Flutter">
    On Flutter, call `login` with a **Partner JWT** after `initialize()`:

    ```dart theme={null}
    Future<LoginResult> login({
      required String authToken,
      OnOtpRequest? onOtpRequest,
    });
    ```

    See [Reference](/airkit/usage/reference) (Flutter tab) and [Flutter overview](/airkit/flutter/overview). Build the JWT using [Partner authentication](/airkit/usage/partner-authentication).
  </Tab>
</Tabs>

* `authToken` : (highly recommended but optional) pass in your [Partner JWT](/airkit/usage/partner-authentication) via the parameter with your `partnerId` inside the payload.
* This would trigger the AIR Kit login dialog with built-in login methods for the user to choose from.

<Info>
  **Session Configuration**

  To configure locale and currency settings, pass `sessionConfig` to the `init()` method. See [Language & Currency Configuration](/airkit/usage/config-language) for details.
</Info>

## Custom Auth (Bring your own Auth)

Instead of using AIR Kit as your authentication provider, AIR Kit supports users that have been already authenticated by your system to skip logging in again when using AIR Kit.

To achieve this, pass in additional properties in the [Partner JWT](/airkit/usage/partner-authentication) during login() , specifically `email` and `partnerUserId` .

When an email is provided, we will verify via a one-time password sent to the specified email since it is used as an identifier in the AIR ecosystem.

An example JWT looks like following:

```json theme={null}
{
  "partnerId": "YOUR PARTNER ID",
  "partnerUserId": "YOUR USER ID", // optional
  "email": "YOUR USER EMAIL", // optional
  "exp": 1728973684,
  "iat": 1728970084
}
```

# User Sessions

After successful login, an `AirLoginResult` object will be returned, which also contains a property `token` generated by us containing the following information:

```json theme={null}
{
  sub: string,
  abstractAccountAddress: string,
  partnerId: string,
  partnerUserId?: string,
  sourcePartnerId?: string
}
```

This token can be used in the future to query some of our sdk functions.

You may validate our token by using the following JWKS endpoint: [https://static.air3.com/.well-known/jwks.json](https://static.air3.com/.well-known/jwks.json)

## Session management

AIR Kit automatically handles session management out of the box. When users return to your app, they would be automatically logged in provided that they have not logged out in the last 30 days.

<Tabs>
  <Tab title="Web">
    * To require users to log in every time they visit your app, set `skipRehydration` to true when initializing the SDK.
    * Call `isLoggedIn` to check the login state of a user.
    * To log out, call `logout()`
    * To update locale or currency settings after initialization, use `updateSessionConfig()`:

    ```tsx theme={null}
    // Update currency or locale
    await airService.updateSessionConfig({
      currency: "EUR",
      locale: "es"
    });
    ```
  </Tab>

  <Tab title="Flutter">
    * To remain logged in (after an app restart), `rehydrate()` can be called to automatically log in a previously logged in user with an existing valid session. Otherwise login() needs to be called.
  </Tab>
</Tabs>

## EOA Wallet Authentication (optional add-on)

EOA-based authentication is available as an optional customization on top of the default AIR Account login flow.
This allows your users to authenticate using any EOA wallet (e.g., MetaMask, Trust Wallet) while still benefiting from the AIR Account identity stack. The EOA wallet is used only for authentication and identity verification. It does not replace the underlying MPC-based account abstraction or control mechanisms. In effect, the wallet address serves purely as a login identifier, while account control remains securely managed by AIR.

### Why enable EOA auth?

* Seamlessly supports existing “Connect Wallet” flows
* Zero disruption to current users
* Adds AIR Account–powered authentication without requiring UX changes
* Works alongside Web2 and other login methods

If your application already uses EOA wallet login, you can enable AIR Account authentication on top of it—ensuring a unified identity experience while preserving your existing flow.

### How to request EOA authentication

EOA auth is not enabled by default.
To enable it for your project, please contact our support team with the following details:

### EOA auth enablement request template

**Subject:** Request to Enable EOA Authentication for \<Project Name >

**Email Body:**

```
Hi Team,

I would like to request **EOA authentication** to be enabled for our project.

**Project Name:**
**Partner ID: (Can be obtained from the Dev dashboard: https://developers.sandbox.air3.com/dashboard/general):**
**Environment:** (Production / Sandbox / Both)

**Current Login Method:**
(e.g., Connect Wallet, Web2 login, AIR Account)

**Reason for Enabling EOA Auth:**
(e.g., we support existing EOA wallet login and want to integrate AIR Account without disrupting our users)

Please let us know if you require any additional information or configuration details.

Thank you!
```