SE DocsSE Docs
Developer

OAuth Applications

Register OAuth 2.1 applications to let third-party services access your team data with user-approved permissions.

Shocking Energy supports OAuth 2.1 for secure third-party access to team data. OAuth applications allow external services to request access on behalf of a user, with explicit consent and scoped permissions.


When to use OAuth

Use caseRecommended method
AI assistant (Claude.ai)OAuth (automatic)
Internal script or automationAPI key
Third-party integrationOAuth application
CI/CD pipelineAPI key

OAuth is ideal when:

  • A third-party service needs to access team data on behalf of a user
  • You want users to approve specific permissions before granting access
  • You need time-limited tokens that can be refreshed automatically

How OAuth works

Shocking Energy implements the OAuth 2.1 Authorization Code flow with PKCE (Proof Key for Code Exchange).

Client redirects user

The third-party application redirects the user to the Shocking Energy authorization endpoint with a client_id, redirect_uri, requested scope, and a PKCE code_challenge.

User approves access

The user signs in to Shocking Energy and reviews the requested permissions on the consent screen. They can see the application name, description, and the specific scopes being requested.

Authorization code issued

After approval, Shocking Energy redirects back to the application's redirect_uri with a short-lived authorization code.

Code exchanged for tokens

The application exchanges the authorization code (plus the PKCE code_verifier) for an access token and refresh token at the token endpoint.

Access team data

The application uses the access token in the Authorization: Bearer header to make API or MCP requests. When the access token expires, use the refresh token to obtain a new one.


Create an OAuth application

Navigate to Settings > Developer and select the OAuth Applications tab.

Click Create Application.

Fill in the application details:

  • Name — a human-readable name shown to users on the consent screen
  • Description — a brief explanation of what the application does (optional)
  • Website — the application's homepage URL (optional)
  • Redirect URIs — one or more URLs where users will be redirected after authorization. At least one is required.

Choose permissions:

  • Full access (apis.all) — all read and write permissions
  • Read only (apis.read) — all read-only permissions
  • Custom — select individual scopes (see Permissions)

Click Create. Copy the Client ID and Client Secret immediately — the secret is only shown once.

Copy the client secret immediately after creation. It cannot be retrieved later. If lost, you must delete the application and create a new one.


OAuth endpoints

All endpoints are relative to your API base URL (e.g. https://api.jobway.ai).

Discovery

EndpointDescription
GET /.well-known/oauth-authorization-serverAuthorization server metadata (RFC 8414)
GET /.well-known/oauth-protected-resourceProtected resource metadata (RFC 9728)

Authorization flow

EndpointDescription
GET /oauth/authorizeGet application info for the consent screen
POST /oauth/authorizeCreate an authorization code (user must be authenticated)
POST /oauth/tokenExchange authorization code or refresh token for access token
POST /oauth/revokeRevoke an access or refresh token
POST /oauth/registerDynamic client registration

Authorization request

Redirect the user to the authorization endpoint:

GET /oauth/authorize?
  client_id=YOUR_CLIENT_ID&
  redirect_uri=https://example.com/callback&
  scope=jobs.read+flows.read+team.read&
  code_challenge=BASE64URL_ENCODED_CHALLENGE&
  code_challenge_method=S256&
  state=RANDOM_CSRF_TOKEN
ParameterRequiredDescription
client_idYesYour OAuth application's client ID
redirect_uriYesMust match one of the registered redirect URIs
scopeNoSpace-separated scopes. Defaults to the application's registered scopes
code_challengeYes (public clients)PKCE code challenge (Base64URL-encoded SHA-256 hash of the code verifier)
code_challenge_methodNoMust be S256
stateRecommendedRandom string to prevent CSRF attacks

Token exchange

Exchange the authorization code for tokens:

curl -X POST https://api.jobway.ai/oauth/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=authorization_code" \
  -d "code=AUTHORIZATION_CODE" \
  -d "redirect_uri=https://example.com/callback" \
  -d "client_id=YOUR_CLIENT_ID" \
  -d "client_secret=YOUR_CLIENT_SECRET" \
  -d "code_verifier=YOUR_CODE_VERIFIER"

Response:

{
  "access_token": "se_oauth_...",
  "refresh_token": "se_rt_...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "jobs.read flows.read team.read"
}

Refresh tokens

Access tokens expire after 2 hours. Use the refresh token to obtain a new access token:

curl -X POST https://api.jobway.ai/oauth/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=refresh_token" \
  -d "refresh_token=YOUR_REFRESH_TOKEN" \
  -d "client_id=YOUR_CLIENT_ID" \
  -d "client_secret=YOUR_CLIENT_SECRET"

Revoke tokens

Revoke an access or refresh token when it is no longer needed:

curl -X POST https://api.jobway.ai/oauth/revoke \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "token=TOKEN_TO_REVOKE"

The revoke endpoint always returns 200 OK regardless of whether the token was valid.


Dynamic client registration

MCP-compatible AI clients like Claude.ai can register themselves automatically via the registration endpoint (no pre-created client ID required). Claude Connectors use this DCR flow when you add a custom connector URL:

curl -X POST https://api.jobway.ai/oauth/register \
  -H "Content-Type: application/json" \
  -d '{
    "client_name": "My AI Assistant",
    "redirect_uris": ["https://example.com/callback"],
    "scope": "jobs.read flows.read team.read",
    "token_endpoint_auth_method": "none"
  }'

Set token_endpoint_auth_method to "none" for public clients (e.g. single-page apps, CLI tools) that cannot securely store a client secret. Public clients must use PKCE.


Public vs confidential clients

TypeAuth methodPKCE requiredUse case
Confidentialclient_secret_postOptionalServer-side applications that can securely store the client secret
PublicnoneRequiredSingle-page apps, CLI tools, mobile apps that cannot store secrets

Security considerations

  • PKCE is mandatory for public clients — prevents authorization code interception attacks
  • Redirect URIs are validated — only registered URIs are accepted
  • Client secrets are hashed — stored using SHA-256, never in plain text
  • Rate limiting — token and registration endpoints are rate-limited to 20 requests per 15 minutes
  • Token revocation — users and applications can revoke tokens at any time
  • Scope restriction — tokens can only access resources within their granted scopes

OAuth 2.1 removes support for the implicit grant and resource owner password credentials grant. Only the authorization code flow (with PKCE) is supported.

On this page