Authentication

Documentation Index

Fetch the complete documentation index at: https://docs.mightynetworks.com/llms.txt

Use this file to discover all available pages before exploring further.

​

Overview

​

Why OAuth 2.0

• Whose data is this? Every Headless API call resolves against a specific user’s permissions in a specific network. A member token can only see what that member can already see in the product; a host token additionally exposes host-level fields. There is no “superuser” mode and no way for a third-party app to read data the authorized user can’t.
• Did the user actually consent? Before an application receives a token, the user is shown a consent screen listing the application name and the scopes it’s requesting, and explicitly approves. Mighty — not the application — collects the password. The application never sees the user’s credentials and can never act beyond the scopes the user approved.

• Delegated access without credential sharing. Users authorize applications through Mighty’s login flow. Applications never handle passwords, MFA codes, or session cookies.
• Scoped, revocable tokens. Tokens are bound to a specific user, application, and scope set, with a short expiry. A leaked token has a small blast radius; users (and hosts) can revoke an application’s access without rotating their password.
• A model that fits every client type. Server-side web apps use the Authorization Code flow with a client secret. Mobile, desktop, and single-page apps use Authorization Code + PKCE and ship no secret at all. Both target the same authorization server and the same token endpoint.
• An ecosystem of tooling. OAuth 2.0 client libraries exist for every language and framework — there’s no Mighty-specific SDK to learn, and standard tools (Postman, curl, framework auth middleware) work out of the box. Mighty publishes the canonical endpoints at /.well-known/oauth-authorization-server per RFC 8414.

​

Create an OAuth application

​

Endpoints

https://:network_subdomain.mn.co/oauth/authorize
https://:network_subdomain.mn.co/oauth/token

https://:network_subdomain.mn.co/.well-known/oauth-authorization-server

​

Authorization Code flow

​

Step 1 — Redirect to the authorization endpoint

https://:network_subdomain.mn.co/oauth/authorize
  ?response_type=code
  &client_id=YOUR_CLIENT_ID
  &redirect_uri=YOUR_REDIRECT_URI
  &scope=SPACE_SEPARATED_SCOPES
  &state=RANDOM_OPAQUE_STRING
  &code_challenge=PKCE_CHALLENGE
  &code_challenge_method=S256

​

Step 2 — User approves

https://app.example.com/oauth/callback?code=AUTH_CODE&state=YOUR_STATE

​

Step 3 — Exchange the code for an access token

curl https://:network_subdomain.mn.co/oauth/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=authorization_code" \
  -d "code=AUTH_CODE_FROM_REDIRECT" \
  -d "redirect_uri=YOUR_REDIRECT_URI" \
  -d "client_id=YOUR_CLIENT_ID" \
  -d "client_secret=YOUR_CLIENT_SECRET" \
  -d "code_verifier=PKCE_VERIFIER"

{
  "access_token": "eyJhbGciOi...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "def50200...",
  "scope": "read:userinfo read:posts"
}

​

Step 4 — Call the Headless API

POST /graphql HTTP/1.1
Host: api.mn.co
Authorization: Bearer eyJhbGciOi...
Content-Type: application/json

{ "query": "query { me { id name } }" }

​

Refreshing tokens

curl https://:network_subdomain.mn.co/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"

• The user revokes the application’s access.
• A host deletes the OAuth application.
• The user changes their password or is signed out network-wide.
• The refresh token reaches its absolute lifetime.

​

Scopes and permissions

• A read:posts scope granted to a member only exposes what the member could already see in the product.
• A host:read:network_posts scope is only effective when the authorized user is a host of the network — a member who approves it still won’t get host-level reads.

​

Errors

​

Security best practices

• Use PKCE everywhere. Required for public clients; recommended for confidential clients as defense in depth.
• Validate state. Generate a cryptographically random state per authorization request and reject any callback whose state doesn’t match. This is your CSRF defense.
• Pin redirect URIs. Register the exact URIs your app uses. Never register a wildcard, a path you don’t control, or an open redirector.
• Treat the Client Secret like a password. Store it in a secret manager, never in source control, never in a client bundle. Never ship a secret in a mobile, desktop, or single-page app — use the public client type with PKCE instead.
• Request least privilege. Ask for the narrowest scopes that let the feature work. Broader scopes drive higher consent abandonment and expand the blast radius if a token leaks.
• Persist refresh tokens server-side. Refresh tokens are long-lived credentials. Store them encrypted at rest and never expose them to the browser or to logs.
• Replace applications on suspicion of secret leak. During alpha, programmatic secret rotation is not yet available. If a secret may have leaked, delete the application (which revokes every token under it) and create a replacement.

​

Next steps