Skip to main content

OAuth

OAuth lets third-party apps sign users in with Waysdrop and access scoped profile data. It is separate from API keys — API keys authenticate your server to the delivery API; OAuth lets your users authorize your app to act on their behalf.

OAuth vs API keys

Environments

Discovery document: GET {issuer}/oauth/.well-known/openid-configuration

Step 1 — Open OAuth Apps in the dashboard

  1. Sign in to the API dashboard (or staging).
  2. In the sidebar, open OAuth Apps.
This page lists every OAuth application tied to your account. OAuth apps are for Sign in with Waysdrop — they are not API keys.

Step 2 — Create an OAuth app

Click Create App and fill in the form: Default scopes (openid, profile, email) are always included and cannot be removed. Click Create App when done.

Step 3 — Save your Client ID and Client Secret

After creation, a modal shows your credentials:
  • Client ID — format: wdo_{env}_{32 hex chars} (e.g. wdo_live_a1b2c3...). Safe to expose in client-side code.
  • Client Secret — format: wdos_{64 hex chars}. Shown once. Store it securely; it cannot be retrieved again.
Copy the client secret immediately. If you lose it, open the app details → Credentials tab → Regenerate secret. The old secret is invalidated instantly.
On the app details page you can also:
  • Copy OAuth endpoints (authorize, token, userinfo, revoke)
  • Edit redirect URIs and permissions
  • Activate / deactivate the app
  • Delete the app (soft-deletes, revokes all grants and refresh tokens)

Step 4 — Redirect the user to authorize

Send the user’s browser to the authorization endpoint:
Query parameters Example authorize URL (confidential client)
What the user sees
  1. Sign in — Waysdrop login (email or phone + password)
  2. Consent — Lists requested permissions; user clicks Authorize or Cancel
On success, the user is redirected to your redirect_uri with:
On denial:
Authorization codes expire in ~2 minutes and are single-use.

Step 5 — Exchange the code for tokens

Exchange the authorization code at the token endpoint:
Authorization code grant
client_secret is required for confidential clients. code_verifier is required when PKCE was used during authorization. 200 Response

Step 6 — Use the access token in your app

Send the access token as a Bearer token:
Userinfo response (fields depend on granted scopes)
Use sub as the stable user identifier in your database.

Refresh tokens

When the access token expires, refresh it:
Each refresh rotates the refresh token — store the new one and discard the old.

Revoke tokens

Revoke a refresh token:
Returns { "revoked": true }. Access tokens are short-lived JWTs and expire on their own.

Scopes

Only scopes listed in your app’s allowed scopes can be requested. The consent screen shows exactly what the user is granting.

PKCE (public clients)

PUBLIC clients (SPAs, mobile apps) must use PKCE:
  1. Generate a random code_verifier (43–128 chars)
  2. Compute code_challenge = BASE64URL(SHA256(code_verifier))
  3. Send code_challenge and code_challenge_method=S256 on authorize
  4. Send code_verifier on token exchange
Public clients do not receive a client secret.

Code examples

TypeScript (confidential server)

Golang (confidential server)


OAuth endpoints reference

App management endpoints (/oauth/apps/*) require a dashboard session JWT — they are for creating and managing apps, not for the end-user OAuth flow.

Common errors