Credential types
Overview
This guide describes the credential types available for accessing data sources with Posit Workbench and Posit Connect. Understanding credential scope and lifetime will help you choose the right approach for development and deployment.
Credential scope
Credentials fall into two broad scopes.
| Scope | What it is | When to use |
|---|---|---|
| User | A credential tied to one individual. Data access reflects that user’s own permissions. | The preferred, most secure choice. Each viewer sees only the data they are authorized to access. Common with strong governance models such as Databricks and Snowflake. |
| One-to-many (service account) | A credential shared across many users or systems, with a single fixed set of permissions. | Applications that run autonomously, or data sources without user-level permissions. You manage which viewers can access the shared data. |
Choosing the right scope
As you consider credential types for your use case, note that the credentials you use when deploying to Connect often differ from those in your development environment. When you run code on Connect, multiple users often access the content you share. When your content accesses a data source, you need to decide whether:
- Each viewer uses their own credentials, so they see content based on their own data permissions (user credential).
- Every viewer uses a shared service account (one-to-many credential). If the publisher uses their own user credential in deployed content, it becomes a one-to-many credential because all viewers share it.
Generally, choose a user credential. It is more secure because viewers see only the data they are authorized to access. Even if you write a query that requests data the viewer cannot access, the query does not expose it.
In contrast, one-to-many configurations make the developer responsible for showing each person the correct data. You must also manage the service principal permissions so that everyone in the content audience can access the shared data.
Credential lifetime
Scope determines whose permissions a credential carries. Lifetime determines how long the credential stays valid, and the two are independent: a credential of either scope can be long-lived or ephemeral. Lifetime involves a trade-off between security and ease of implementation.
| Lifetime | What it is | When to use |
|---|---|---|
| Long-lived | A credential that stays valid until you revoke it, such as a username and password, personal access token (PAT), or API key. | Easier to implement, but less secure because of its long life. Never hard-code these credentials into application code. |
| Ephemeral | A short-lived credential that expires automatically, such as an OAuth token or Kerberos ticket. | The more secure choice. Traditionally harder to implement due to complex server configuration or interactive token refresh flows. |
Choosing scope and lifetime together
Choose the scope based on your use case, then choose the most secure lifetime your data source and platform support. Prefer ephemeral credentials whenever they are available, because short-lived tokens limit the damage if a credential leaks. The table below maps both dimensions to common examples:
| Scope | Long-lived | Ephemeral |
|---|---|---|
| User | A personal password or API key tied to one individual | A per-user OAuth token, such as a Workbench Advanced Managed Credential or a Connect viewer credential |
| One-to-many (service account) | A shared service account password or API key | A service principal OAuth token, such as a Connect service account integration |
The most secure combination is a user-scoped, ephemeral credential. Workbench and Connect make this combination practical for many data sources.
How Workbench and Connect help
Workbench and Connect manage secure, ephemeral OAuth credentials so you can follow security best practices without losing productivity.
Posit Workbench
Workbench provides OAuth integrations with target data sources to simplify ephemeral token use in development:
- Advanced Managed Credentials (Databricks, Snowflake, AWS): Users select their credential at session start and Workbench handles retrieval and refresh automatically. You do not need to store credentials in code, configuration files, or environment variables. SDKs, CLIs, and higher-level packages just work.
- Custom OAuth integrations: Enable low-friction workflows with ephemeral OAuth tokens for services like Azure, Google Cloud, GitHub, or custom providers.
Posit Connect
Connect brings OAuth integrations to deployed content with ephemeral tokens for secure data access:
- Supports both viewer credentials (user scope) and service accounts (one-to-many scope)
- Keeps secrets out of application code
- Available for many common data sources, including Databricks, Snowflake, AWS, Google, Microsoft, GitHub, Salesforce, and custom OAuth providers