OAuth

Sign in with Teamcast

A standards-compliant OAuth 2.1 authorization server for delegated, scoped access to a recruiter's Teamcast account.

Teamcast's OAuth provider lets a partner application act on behalf of a recruiter without ever handling their password. It supports the authorization_code grant (with mandatory PKCE) for interactive "Sign in with Teamcast" flows, plus client_credentials for machine-to-machine access, and rotating refresh_token grants.

This is separate from the X-API-Key Integration API keys described in API Reference → Authentication. Use API keys for server-to-server integration; use OAuth when a partner app needs a recruiter to explicitly authorize it.

Property	Value
Discovery	`GET /.well-known/oauth-authorization-server`
JWKS	`GET /.well-known/jwks.json`
Access token	RS256 signed JWT (at+jwt), 900s default TTL
Refresh token	Opaque, SHA-256 hashed at rest, rotating with reuse-detection, 30d default TTL
PKCE	S256 only — required for all public (browser/mobile) clients
Grants	`authorization_coderefresh_tokenclient_credentials`

How it fits together

Your app redirects the recruiter's browser to GET /oauth/authorize with your registered client_id, PKCE challenge, and requested scopes.
Teamcast issues a short-lived, signed pending-request token (PRT) and 302s to tc-web's consent screen, which logs the recruiter in if needed and renders the client's requested scopes.
On Allow, tc-web calls back into tc-core to mint an authorization code, then redirects to your redirect_uri with ?code=....
Your backend exchanges the code (+ PKCE verifier) at POST /oauth/token for an access + refresh token pair.

Integrate your app

Step-by-step authorization_code + PKCE flow with request/response examples.

Endpoint reference

Every OAuth endpoint: authorize, token, introspect, revoke, consents.

Authentication overview

How OAuth, API keys, and user JWTs resolve to one principal.

Was this page helpful?

Previous← Permission reference

NextIntegrate your app →