Architecture and Security Overview
This section explains how OAuth-based authentication works when connecting Snowflake to ADOC, why the OAuth flow is handled by the Acceldata Control Plane, and what users need to know from a security and operational perspective.
Authentication Flow Overview
When configuring Snowflake as a data source in ADOC, authentication can be set up using either:
- OAuth-based authentication, or
- Credential-based authentication (username/password)
- Eternal OAuth (Microsoft Entra ID)
- Key Pair Value
The origin of the authentication request differs depending on the method:
| Authentication Method | Where the Request Originates | When It Occurs |
|---|---|---|
| OAuth | Acceldata Control Plane | One-time (during setup or token refresh) |
| Non-OAuth (Credentials / Key Pair) | Customer Data Plane | During execution |
This difference is intentional and driven by how OAuth works and how ADOC is architected.
Why OAuth Authentication Is Handled by the Control Plane
OAuth authentication requires interaction with Snowflake’s OAuth authorization service, which involves:
- Secure token exchange
- Client credential validation
- Token lifecycle management
These functions are implemented in the Acceldata Control Plane for the following reasons:
Centralized and Secure Credential Management
The Control Plane is responsible for:
- Securely storing OAuth client credentials
- Managing access tokens and refresh tokens
- Enforcing tenant isolation and access control
Keeping OAuth logic centralized avoids distributing sensitive authentication logic across multiple customer-managed environments.
One-Time, Non-Data Access Operation
OAuth authentication:
- Does not query customer data
- Does not scan tables, schemas, or metadata
- Only establishes authorization context
Once authentication succeeds, all data access happens from the Data Plane, not the Control Plane.
Consistent Tenant Governance
Since the Control Plane is multi-tenant and identity-aware, it ensures:
- OAuth tokens are scoped correctly per tenant
- Access mechanisms are in place and consistently enforced
- Auditability and traceability of authentication events
What Accesses Snowflake During OAuth Setup
During OAuth authentication, the Control Plane communicates only with Snowflake’s OAuth endpoints.
What Is Accessed
- Snowflake OAuth authorization service
- Token issuance and validation
Refresh Token Validity (in seconds)
When configuring a Snowflake connection using OAuth, the Refresh Token Validity field defines how long the OAuth refresh token remains valid after authentication.
This value must be entered in seconds.
For example:
7776000seconds = 90 days
How It Works
When you click Authenticate, ADOC initiates an OAuth flow with Snowflake.
Snowflake issues:
- An access token (short-lived)
- A refresh token (longer-lived)
The refresh token allows ADOC to automatically request new access tokens without requiring repeated login.
The value entered in the Refresh Token Validity field determines how long the refresh token remains usable before reauthentication is required.
What Is NOT Accessed
- Customer databases, schemas, or tables
- Data contents
- Query execution endpoints
- Warehouses or compute resources
After Authentication
Once OAuth is complete:
- OAuth tokens are securely stored
- All data discovery, profiling, policy execution, and monitoring are performed from the customer Data Plane
Frequency of Control Plane Access to Snowflake
| Activity | Frequency |
|---|---|
| Initial OAuth authorization | One-time during setup |
| Token refresh | Only when the OAuth token expires |
| Metadata scanning / data access | Never from Control Plane |
Token refresh frequency depends on:
- Snowflake OAuth token lifetime configuration
- OAuth client settings
Data Plane Access to Snowflake (Post-Authentication)
After OAuth authentication:
- The Data Plane connects to Snowflake using the authorized context
- All runtime operations occur from within the customer’s network boundary
This includes:
- Schema and metadata discovery
- Profiling jobs
- Policy execution (Data Quality, Reconciliation, Drift, Freshness)
- Pushdown execution (if enabled)
Required Snowflake Permissions
ADOC connects to Snowflake using a Snowflake user and an associated role. Follow the principle of least privilege:
- Create a dedicated role for ADOC (recommended).
- Grant only the access needed for the databases/schemas/tables you want ADOC to discover, profile, and run reliability checks on.
- Grant warehouse usage for the compute that ADOC should use to execute queries.
What access is required (minimum)
At a minimum, the ADOC role should have:
| Permission Category | Required Privilege | What It Enables |
|---|---|---|
| Database access | USAGE on database(s) | Allows ADOC to “see” the database and reference objects inside it |
| Schema access | USAGE on schema(s) | Allows ADOC to list and access schema objects |
| Table access | SELECT on table(s) | Allows profiling, sampling, and rule evaluation (DQ, reconciliation, etc.) |
| Future tables (recommended) | SELECT ON FUTURE TABLES | Ensures newly created tables are automatically accessible without re-granting |
| Compute | USAGE on warehouse | Allows ADOC to run queries using the designated warehouse |
| Optional: Shared/sample databases | IMPORTED PRIVILEGES | Needed only if you want ADOC to access Snowflake-provided shared datasets (e.g., SNOWFLAKE_SAMPLE_DATA) |
Recommended setup pattern
1) Create a dedicated ADOC role
Use an admin role (commonly USERADMIN or equivalent) to create a role dedicated to ADOC access.
- Purpose: isolate privileges, simplify audits, and enable easy revocation.
2) Grant data access to the role (scoped)
Grant access only to the datasets ADOC should work with.
For each database ADOC should access, grant:
USAGEon databaseUSAGEon schemas (either specific schemas or all schemas in the database)SELECTon tables (existing + future tables)
This covers the common ADOC requirements for:
- Discovery (listing databases/schemas/tables)
- Profiling (sampling/selecting from tables)
- Reliability policies (rule evaluation via SELECT queries)
3) Assign the role to the Snowflake user ADOC uses
Grant the ADOC role to the Snowflake user and set it as the default role. This ensures ADOC sessions consistently use the correct privileges.
4) Grant warehouse usage
Grant USAGE on the Snowflake warehouse that ADOC should use. Without this, ADOC can authenticate but cannot execute queries.
What Users Should Know Before Setup (Snowflake + OAuth)
Before configuring Snowflake using OAuth authentication in ADOC, review the following considerations.
1. Network and Security Considerations
- During OAuth-based authentication, the authorization request originates from the Acceldata Control Plane.
- This interaction is limited to Snowflake’s OAuth and token endpoints.
- No customer data is queried or transferred during this authentication exchange.
- After authentication is completed, operational queries (discovery, profiling, reliability checks) are executed from the Data Plane, not the Control Plane.
2. Data Access Boundaries
ADOC maintains a strict separation of responsibilities:
| Component | Responsibility |
|---|---|
| Control Plane | Handles OAuth flow, token exchange, configuration metadata |
| Data Plane | Executes all SQL queries against Snowflake |
This means:
- The Control Plane does not read tables, run
SELECTqueries, or process customer datasets. - All profiling, policy execution, reconciliation, and metadata extraction occurs from the customer-managed Data Plane environment.
This separation supports tenant isolation and enterprise security requirements.
3. Audit and Compliance
When using OAuth with Snowflake:
- OAuth authentication events are logged and auditable within Snowflake.
- Token issuance and expiration follow Snowflake’s OAuth policies.
- ADOC does not store Snowflake passwords when OAuth is used.
- Token usage aligns with Snowflake session and role-based access controls.
- ADOC enforces tenant isolation at the platform level.
Users can monitor authentication and session activity through standard Snowflake audit capabilities.
4. Authentication Frequency
Users often ask how frequently the Control Plane communicates with Snowflake.
- The initial OAuth handshake occurs during data source configuration.
- Token refresh operations occur based on Snowflake’s configured token expiration policy.
- The Control Plane does not continuously poll Snowflake.
- Operational data access happens from the Data Plane during:
- Asset discovery
- Profiling
- Policy execution
- Reconciliation
- Monitoring jobs
This means the Control Plane interaction is event-driven (authentication and refresh), not workload-driven.
5. Required Snowflake Privileges
Using OAuth does not change required object permissions.
The Snowflake role used by ADOC must still have:
- USAGE on database(s)
- USAGE on schema(s)
- SELECT on tables (and future tables recommended)
- USAGE on the warehouse used for query execution
- Optional: IMPORTED PRIVILEGES for shared databases (if monitored)
OAuth replaces password-based authentication but does not change access scope requirements.
6. Recommended Setup Practices
To ensure a secure and maintainable deployment:
- Use a dedicated Snowflake role for ADOC.
- Grant access only to required databases and schemas.
- Set the ADOC role as the Snowflake user’s default role.
- Confirm warehouse sizing supports profiling and policy workloads.
- Validate OAuth token lifetimes align with operational expectations.
- Coordinate with security teams if outbound Control Plane endpoints must be allowlisted.