Endpoint reference
Every endpoint this authorization server exposes.
The authoritative, machine-readable version of this page is
/.well-known/openid-configuration.
Read it at runtime rather than hardcoding what is below.
| Purpose | Method & path | Auth |
|---|---|---|
| Authorization | GET /oauth-authorize.php | User session |
| Token | POST /oauth/token | Client |
| UserInfo | GET /oauth/userinfo | Bearer access token |
| Revocation | POST /oauth/revoke | Client |
| Discovery | GET /.well-known/openid-configuration | Public |
| JWKS | GET /oauth/jwks.json | Public |
The authorization endpoint keeps its .php suffix — it is the browser-facing
consent page, not an API route. Requesting it also issues a 301 to the
extensionless path; browsers follow it and the query string is preserved, but you will see
the extra hop in raw traffic.
POST /oauth/token
Accepts application/x-www-form-urlencoded (per RFC 6749) or JSON.
grant_type=authorization_code
grant_type | authorization_code |
|---|---|
code | The code from the callback. Single use, 60-second lifetime. |
redirect_uri | Byte-identical to the authorization request. |
client_id | Your client. |
client_secret | Confidential clients only. |
code_verifier | The original PKCE verifier. |
grant_type=refresh_token
grant_type | refresh_token |
|---|---|
refresh_token | The refresh token from a previous exchange. |
client_id / client_secret | Client authentication. |
The token endpoint returns a bare OAuth2 response, not the
{success, message, data} envelope used elsewhere in this product. Parse it as
a standard token response.
GET /oauth/userinfo
curl https://account.gocosys.com/oauth/userinfo \
-H "Authorization: Bearer ACCESS_TOKEN"
Requires a bearer access token. Returns the claims covered by the granted scopes — see
Scopes & claims. A missing, malformed, expired or
revoked token gives TOKEN_INVALID (401).
POST /oauth/revoke
curl -X POST https://account.gocosys.com/oauth/revoke \
-d token=ACCESS_OR_REFRESH_TOKEN \
-d token_type_hint=refresh_token \
-d client_id=YOUR_CLIENT_ID \
-d client_secret=YOUR_CLIENT_SECRET
RFC 7009. Idempotent — it always answers 200, including for a token that was
never valid, so you cannot use it to probe whether a token exists.
GET /oauth/jwks.json
Always returns exactly this, and always will:
{"keys": []}
This is correct, not a misconfiguration. ID tokens are signed with
HS256, a symmetric algorithm whose key is your client_secret.
Publishing that key would hand anyone the ability to forge your tokens, so there is
nothing to put in the key set. The endpoint exists only so that OIDC libraries which
fetch jwks_uri during discovery receive a valid document instead of a
404.
Do not wait for keys to appear here. Point your library at your client secret instead —
see Tokens & refresh. If your library cannot be
told to verify HS256 with a shared secret and insists on fetching a public
key, it cannot verify our tokens; that is a library limitation, not an outage.
GET /.well-known/openid-configuration
Standard discovery document. Fields worth noting:
response_types_supported | ["code"] |
|---|---|
grant_types_supported | ["authorization_code", "refresh_token"] |
code_challenge_methods_supported | ["S256"] |
token_endpoint_auth_methods_supported | ["client_secret_post", "none"] |
id_token_signing_alg_values_supported | ["HS256"] |
scopes_supported | ["openid", "profile", "email"] |