# Authentication Logs

Collects Snowflake authentication events (login attempts) for monitoring sign-in activity, MFA usage, and failed logins.

**Sync Type: Incremental**

## Requirements

1. You must have a Snowflake account and access to create a service account user, create a role, and assign it.
2. Monad uses key pair authentication — follow the Snowflake docs on how to set this up [here](https://docs.snowflake.com/en/user-guide/key-pair-auth). Be sure to have your private and public keys handy.
3. Create a new Snowflake service account user:
```sql
CREATE USER monad_service_account
    COMMENT = 'Service account for monad snowflake authentication logs input'
    TYPE = 'service'
    RSA_PUBLIC_KEY='Your RSA Public Key';
```
4. Create a role and grant it the access needed to read the `LOGIN_HISTORY` view. Reading the view is a `SELECT`, so it runs on a warehouse and the role needs `USAGE` on one:
```sql
CREATE ROLE monad_login_history_role;

-- Read access to the account-level usage views (LOGIN_HISTORY lives here)
GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE monad_login_history_role;

-- A warehouse is required to execute the query
GRANT USAGE ON WAREHOUSE your_warehouse TO ROLE monad_login_history_role;

-- Grant the role to the service account
GRANT ROLE monad_login_history_role TO USER monad_service_account;
```
5. To read organization-wide logins (the `organization_usage` source), the input must connect to the **organization account** with a role that can read `SNOWFLAKE.ORGANIZATION_USAGE` (typically `ACCOUNTADMIN`).

## Details

Monad reads Snowflake's built-in `LOGIN_HISTORY` view on the schedule defined by `cron`, tracking the latest `EVENT_TIMESTAMP` it has processed and fetching only new events on each run.

Choose where to read from with the **Source** setting:

- **`account_usage`** — `SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY`: all login attempts for the current account. ~365-day retention, up to ~2 hours of latency.
- **`organization_usage`** — `SNOWFLAKE.ORGANIZATION_USAGE.LOGIN_HISTORY`: login attempts across every account in the organization. Requires an **Enterprise (or higher) edition** account, up to ~24 hours of latency, and must be run from the organization account.

> **Note:** Unlike the Users and Grants inputs (which use metadata `SHOW` commands), reading `LOGIN_HISTORY` is a `SELECT` and therefore runs on the configured virtual warehouse, consuming compute credits. Use a small, auto-suspending warehouse to keep this cost minimal.

> **Scheduling:** Snowflake populates `LOGIN_HISTORY` with a latency of up to ~2 hours (up to ~24 hours for `organization_usage`), so events do not appear in the view immediately. Set the **Cron** schedule to run **no more often than every 2 hours** — a more frequent schedule wastes compute polling for data that isn't available yet and won't surface events any sooner.

## Configuration
The following configuration defines the input parameters. Each field's specifications, such as type, requirements, and descriptions, are detailed below.

#### Settings

| Setting | Type | Required | Description |
|---------|------|----------|-------------|
| Account | string | Yes | The unique identifier for your Snowflake account, typically in the form of 'organization-account_name' |
| User | string | Yes | The username of the Snowflake account used to establish the connection |
| Role | string | Yes | The name of the role to use (must be able to read the LOGIN_HISTORY view) |
| Warehouse | string | Yes | The Snowflake virtual warehouse used to execute the query (reading LOGIN_HISTORY runs on compute) |
| Source | string | Yes | The view to read from: `account_usage` (current account) or `organization_usage` (all accounts in the organization — requires an Enterprise or higher edition account). Default: `account_usage` |
| Authentication Type | string | Yes | Authentication method: "password" or "private key" (default: "private key") |
| Cron | string | Yes | Cron expression defining the sync schedule. Because `LOGIN_HISTORY` has up to ~2 hours of latency, schedule no more often than every 2 hours (e.g., "0 */2 * * *"). |

#### Secrets

| Secret | Type | Required | Description |
|---------|------|----------|-------------|
| Private Key | string | Conditional | The private key used for authentication (required if using private key auth) |
| Password | string | Conditional | The user's password (required if using password auth) |

**Note:** One of Private Key and Password is used to authenticate with this input, based on the selected Authentication Type.

## Sample Record

```json
{
  "EVENT_ID": 384729104857,
  "EVENT_TIMESTAMP": "2026-06-30T14:22:05.123Z",
  "EVENT_TYPE": "LOGIN",
  "USER_NAME": "JSMITH",
  "CLIENT_IP": "203.0.113.42",
  "REPORTED_CLIENT_TYPE": "JDBC_DRIVER",
  "REPORTED_CLIENT_VERSION": "3.13.30",
  "FIRST_AUTHENTICATION_FACTOR": "PASSWORD",
  "SECOND_AUTHENTICATION_FACTOR": "DUO_PUSH",
  "IS_SUCCESS": "YES",
  "ERROR_CODE": null,
  "ERROR_MESSAGE": null,
  "RELATED_EVENT_ID": 0,
  "CONNECTION": null,
  "CLIENT_PRIVATE_LINK_ID": null,
  "FIRST_AUTHENTICATION_FACTOR_ID": null,
  "SECOND_AUTHENTICATION_FACTOR_ID": null,
  "LOGIN_DETAILS": null
}
```