Documentation / Platform glossary / OAuth
OAuth 2.0 is an authorization framework that lets an application access resources on a user's behalf without handling their password. The user approves a scoped grant at the authorization server, and the application receives a token limited to that scope. OAuth authorizes actions; it does not authenticate users.
OAuth defines four roles: the resource owner (usually the user), the client (the application requesting access), the authorization server (which authenticates the owner and issues tokens), and the resource server (which holds the API being accessed).
The central concept is delegated, scoped authorization. Instead of surrendering credentials, the resource owner approves a specific grant — read a calendar, not administer an account — and the client receives an access token representing exactly that permission. Access tokens are deliberately short-lived; a refresh token allows the client to obtain new ones without prompting the user again.
Grant types matter for security. Authorization code with PKCE is the current recommendation for user-facing applications, including single-page and mobile clients. Client credentials covers machine-to-machine access with no user present. The implicit and password grants are deprecated and should not be used in new work.
The most common misunderstanding is treating OAuth as a login mechanism. An access token proves the bearer was granted permission, not who they are. OpenID Connect exists precisely to add that missing identity layer.
OAuth makes integration credentials revocable and narrow. A token can be withdrawn without a password reset, and a compromised token exposes only what its scope allows — which is why scope discipline is the control that matters most in practice.
The recurring failure is over-broad scope: a token requesting full administrative access when it needs read access to one resource turns a minor compromise into a major one.
QueryTek uses OAuth-based authorization for programmatic access so integration credentials are scoped, revocable, and traceable to a caller within a tenant. Public documentation describes the model; grant configuration and credential handling are covered in authenticated onboarding material.
