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

# User Authentication

> Configure how end-users can create accounts and sign in to your deployed application

## Overview

User Authentication settings control how end-users can access your deployed application. These settings have two parts:

1. **Sign-Up Settings**: Whether new users can create accounts (and related options)
2. **Authentication Methods**: How all users (new and existing) can sign in

These settings are separate from [Deployment Users](/members-and-roles)—deployment users are invited directly, while user authentication controls both self-service sign-ups and sign-in methods.

## Sign-Up Settings

### Allow Sign-Ups

When enabled, new users can create accounts on your deployed application. They'll see a sign-up option and can register using the authentication methods you've configured.

When disabled:

* No new users can register
* Users who previously signed up can still sign in
* Deployment Users you've invited can still sign in
* Organization members can still access the app
* You can still configure authentication methods (email/password, Google, etc.)

### Email Verification

When required, users must verify their email address before accessing your application. This helps prevent spam accounts and ensures valid contact information.

### Default User Role

New users who sign up are automatically assigned the **default role** you've configured in your app's custom roles. You can manage which role is the default in [**Settings** → **Roles & Permissions**](https://www.stardeck.ai/projects/~/dashboard/config/roles) — the role marked as "Default" is what new sign-ups receive.

Most applications should use a standard user role as the default, not an admin role. See [Members & Roles](/members-and-roles) for details on creating and configuring custom roles.

## Authentication Methods

### Email & Password

Traditional authentication where users create an account with their email address and a password. When enabled:

* Users see email and password fields on the sign-in form
* A separate sign-up form is available for new users
* Password requirements are enforced automatically

### Social Login

Allow users to sign in using their existing social accounts. Currently supported:

| Provider   | Status      |
| ---------- | ----------- |
| **Google** | Available   |
| Facebook   | Coming soon |
| **LINE**   | Available   |

Social login provides a streamlined experience—users click one button and are authenticated using their existing account.

<Note>
  When only social login is enabled (no email/password), the sign-up and sign-in experience is
  unified. Users simply click "Continue with Google" whether they have an account or not.
</Note>

### LINE Portal Links (Rich Menu)

For LINE-first apps, you can deep-link users straight into a logged-in session by pointing a LINE Official Account rich menu button at your app's login route with LINE pinned as the only auth method.

```
https://<your-app-domain>/api/auth/login?auth_methods=line&returnTo=/membership
```

| Query param    | Description                                                                      |
| -------------- | -------------------------------------------------------------------------------- |
| `auth_methods` | Pin sign-in to LINE only. Use the value `line`. (Snake\_case at the HTTP layer.) |
| `returnTo`     | URL-encoded path the user lands on after login. Defaults to `/` if omitted.      |

The JavaScript SDK equivalent is `signIn({ authMethods: ["line"], returnTo: "/membership" })` — note that the SDK uses camelCase `authMethods` while the URL query parameter is snake\_case `auth_methods`.

<Note>
  Once LINE is enabled and your app is published, the dashboard's **Authentication** settings tab
  shows a copyable LINE portal link you can paste into your rich menu.
</Note>

<Note>
  LINE must be enabled as an auth method for your project, and LINE OAuth must be configured in your
  authentication provider before it can be used. Contact support for setup assistance.
</Note>

## Configuration

To configure user authentication:

1. Navigate to your app in the Stardeck dashboard
2. Go to [**Settings** → **Authentication** tab](https://www.stardeck.ai/projects/~/dashboard/config/auth)
3. Configure your preferred settings
4. Click **Save Changes**

A live preview shows how your sign-in form will appear to users.

## Common Configurations

### Private Application

For applications where only invited users should have access:

* **Allow Sign-Ups**: Disabled
* Invite specific users as [Deployment Users](/members-and-roles) with appropriate roles

### Public SaaS

For applications where anyone can sign up:

* **Allow Sign-Ups**: Enabled
* **Authentication Methods**: Email & Password + Google
* **Email Verification**: Required
* **Default Role**: Your standard user role

### Social-Only Authentication

For a streamlined sign-in experience without passwords:

* **Allow Sign-Ups**: Enabled
* **Authentication Methods**: Google only
* **Default Role**: Your standard user role

Users will only see "Continue with Google" on the sign-in page.

## How It Works

When a user signs up through your deployed application:

1. They create an account using your configured authentication method(s)
2. If required, they verify their email address
3. They're assigned your configured default role
4. They can now sign in to your application

This is different from users you invite directly as Deployment Users—invited users already have a Stardeck account and are assigned a specific role when invited.

## Security Considerations

* **Email Verification**: Enable this for production applications to ensure valid email addresses
* **Default Role**: Use the least-privileged role unless you have a specific reason for elevated access
* **Social Login**: Provides built-in email verification through the provider

## Disable Authentication

For specific use cases, you can completely disable authentication per deployment environment. This is useful for sharing preview deployments with stakeholders who need to see the full admin experience without creating an account.

### When to Use

| Use Case                | Recommended Configuration                                                                  |
| ----------------------- | ------------------------------------------------------------------------------------------ |
| **Admin Flow Previews** | Disable auth for preview deployments so stakeholders can explore the full admin experience |
| **Development**         | Disable auth for sandbox to speed up testing without login friction                        |
| **Client Demos**        | Disable auth for preview to let clients explore the application before committing to setup |

### Configuration

1. Navigate to your app in the Stardeck dashboard
2. Go to **Settings** → **Authentication** tab
3. In the **Disable Authentication** section, toggle the environments where you want to disable auth:
   * **Sandbox**: Your development environment
   * **Preview**: Preview deployments
   * **Production**: Your live deployment
4. Click **Save Changes**
5. Confirm the redeployment when prompted

<Note>
  Changing these settings triggers an automatic redeployment for the affected environments. For
  sandbox, the dev server restarts automatically.
</Note>

<Warning>
  When you disable authentication for production, your application becomes completely public. Anyone
  with the URL can access all features without signing in. Only disable production auth if you
  intentionally want a fully public application.
</Warning>

<Card title="Members & Roles" icon="users" href="/members-and-roles" horizontal>
  Learn about inviting specific users and managing roles
</Card>