> For the complete documentation index, see [llms.txt](https://docs.e6data.com/query-engine/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.e6data.com/query-engine/guides/security/access-tokens.md). # Access tokens How people and applications authenticate to an e6data workspace with access tokens - the credential types, what they carry, and how token auth relates to RBAC. This section explains how people and applications authenticate to an e6data **workspace** for programmatic access - creating tokens, using them, setting an expiry, rotating them, and the security practices around them. e6data uses **token-based authentication** for everything that talks to a workspace over the API: BI tools, notebooks, scripts, CI/CD pipelines, and backend services. A token proves **who** (or **what**) is making a request. It does **not** carry permissions of its own - what a token is allowed to do comes entirely from the [roles and permissions](/query-engine/guides/security/identity-and-rbac/roles-and-permissions.md) bound to its owner. {% hint style="info" %} Tokens are scoped to a single workspace. You need access to a workspace in the e6data Console before you can create one. {% endhint %} ## Token types This table is the canonical reference for e6data credential types. Other pages link here rather than redefining them. | Type | Prefix | Identity it carries | Where you create it | | --------------------------- | -------- | --------------------------------------------------------------- | --------------------------------------------------------------------------------- | | Personal Access Token (PAT) | `e6pat_` | A human user - your own account (your email) | Avatar menu → **User settings → Access tokens** | | Service Account API key | `e6sa_` | A service account - a machine identity, scoped to one workspace | **Administration → Service Accounts → *****\[account]***** → API Keys** | * Use a **Personal Access Token** when a **human** is the actor - for example, connecting Tableau under your own identity, or running a notebook. * Use a **Service Account API key** when a **machine or automated process** is the actor - CI/CD, Airflow, dbt, or backend services. * **"API credentials"** is not a separate thing in e6data - it is just a casual umbrella term. Whenever a tool asks for "API credentials," "an API key," or "a token," you supply one of the values above. {% hint style="warning" %} Never put a PAT in a shared pipeline or CI system. A PAT is tied to your personal account; if you change roles or leave, it stops working and the pipeline breaks. Use a service account for automation. {% endhint %} PATs and service account keys are covered in [Personal access tokens and service account keys](/query-engine/guides/security/access-tokens/pat-and-service-account-keys.md). ## Key concepts | Term | Meaning | | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Workspace-scoped | The workspace is baked into every token. A token issued for one workspace is not valid in another. | | Identity, not permissions | A token has no inline permissions. It only says who you are. All access is decided by role bindings on the user or service account. To restrict what a token can do, change the role binding - not the token. | | Shown once | The full token value is displayed only once, at creation. It cannot be retrieved again. Lose it and you must create a new one. | | Expiry (optional) | A token can have an expiry, entered in days (default 90, maximum 3650), or be set to never expire. Expiry is enforced on every request. | | Rotation | Replacing a token before it expires or after possible exposure to avoid downtime. | | Revocation | Invalidating a token immediately. Revoked tokens stop working at once. | ## How token authentication works e6data separates **who you are** (authentication, proven by the token) from **what you can do** (authorization, decided by role bindings). Every API request runs the same path: 1. The client sends the token in an `Authorization: Bearer` or `X-API-Key` header. 2. e6data validates the token and checks its expiry. An expired or malformed token returns `401 Unauthorized`. 3. The token resolves to an identity - a user or service account. 4. e6data checks that identity's role bindings in the workspace. If a binding allows the requested action, the request runs (`200`); if not, it returns `403 Forbidden`. A perfectly valid token still returns `403` if its owner has no role binding for what it is trying to do. ## Where to find things in the Console | To manage… | Go to | | ----------------------------------- | ------------------------------------------------------ | | Your own access tokens (PATs) | Avatar (top-right) → **User settings → Access tokens** | | Service accounts and their API keys | Left sidebar → **Administration → Service Accounts** | ## See also * [Personal access tokens and service account keys](/query-engine/guides/security/access-tokens/pat-and-service-account-keys.md) - the two credential types in detail. * [Create, use, rotate, and revoke tokens](/query-engine/guides/security/access-tokens/create-use-rotate-revoke.md) - step-by-step. * [Token security best practices](/query-engine/guides/security/access-tokens/token-security-best-practices.md) - storage, least privilege, revocation, and audit. * [Roles and permissions](/query-engine/guides/security/identity-and-rbac/roles-and-permissions.md) - how to assign the permissions a token inherits. * [Sign up and login](/query-engine/get-started/identity-access-setup/sign-up-and-login.md) - how people sign in to the Console. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.e6data.com/query-engine/guides/security/access-tokens.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.