Skip to content
AuthKit

CLI Auth

How CLI Auth works in Paycux, what it is for, and the smallest setup that gets it running.

Introduction

CLI Auth is part of the Paycux platform. This page explains what it does, when to reach for it, and the smallest working setup you can ship.

Everything below applies to both environments. Build and test in staging, then promote the same configuration to production without changing your code — only the API key and client ID differ.

Request device authorization

Every API request is authenticated with a bearer token in the Authorization header. Keys are scoped to a single environment and are shown once at creation — store them in a secret manager, not in source control.

1curl -X GET 'https://api.paycux.com/v1/organizations' \
2 -H 'Authorization: Bearer $PAYCUX_API_KEY'

User confirms the code

A user record holds the identity Paycux resolved for the person: email, name, verification state, and the identities they have linked. It is the object your application should key on.

Users are unique by email within a project. When the same person arrives through a second provider, Paycux links the identity to the existing user rather than creating a duplicate.

AManual code entry

AManual code entry is handled by CLI Auth rather than by your application code. Paycux exposes it through the same API surface as the rest of the platform, so the client you already configured needs no additional setup.

Configuration lives in the dashboard and is versioned per environment. Change it in staging, confirm the behaviour, then apply the same change to production.

BOne-click confirmation

The Paycux CLI wraps the same API the SDKs use. Authenticate once, then run commands against whichever environment you select.

1paycux login
2paycux env use staging
3paycux organizations list

Request tokens

Access tokens are JWTs signed with a rotating key. Verify them against the JWKS endpoint for your client rather than a pinned public key, so rotation never causes an outage.

1https://api.paycux.com/sso/jwks/client_01M4KXD1PZXFWGWE9ZKPCQRAQ

Cache the key set and re-fetch on an unknown key ID. Reject any token whose issuer, audience or expiry does not match what you expect.

Polling best practices

Polling best practices is handled by CLI Auth rather than by your application code. Paycux exposes it through the same API surface as the rest of the platform, so the client you already configured needs no additional setup.

Configuration lives in the dashboard and is versioned per environment. Change it in staging, confirm the behaviour, then apply the same change to production.

Refresh tokens

Refresh tokens are long-lived, single-use and bound to the session they were issued for. Exchanging one returns a new access token and a new refresh token; the old refresh token is invalidated on use.

If a refresh token is replayed, Paycux treats it as a stolen credential and revokes the whole session family. Handle that response by sending the user back through sign-in rather than retrying.