Register an app

Self-service: any GOCOSYS account can register applications and manage its own.

Register it yourself

You do not need an administrator. Sign in to your GOCOSYS account, open Applications in the sidebar, and fill in:

Application name	Shown to users on the consent screen. Use the name they will recognise.
Redirect URIs	One per line. Every address that may receive the authorization code — list development URIs too.
Logo URL	Optional. Appears beside your name on the consent screen.

You see only your own applications. The list is scoped to the account that registered them, enforced server-side — another developer cannot see, revoke or delete yours, and you cannot see theirs.

Applications are created with the openid, profile and email scopes. Need something outside that set? Contact an administrator.

What you get back

client_id — public. It appears in authorization URLs.
client_secret — private. Treat it exactly like a password.

The secret is issued once and cannot be retrieved again. Only a hash is stored. Save it to your secret manager the moment you receive it; if it is lost, the client must be revoked and re-registered under a new client_id.

Redirect URIs are matched exactly

Scheme, host, port and path must all agree with what was registered. These are four different URIs:

https://app.example.com/auth/callback
https://app.example.com/auth/callback/     ← trailing slash
http://app.example.com/auth/callback       ← http, not https
https://app.example.com:8443/auth/callback ← explicit port

A mismatch fails with OAUTH_INVALID_REDIRECT. Register your local development URI — commonly http://localhost:3000/auth/callback — at the same time, or you will not be able to build against it.

Public clients

A single-page app or mobile app cannot keep a secret — anything shipped to a device is readable. Say so when you register, and the client is set up to authenticate with PKCE alone (token_endpoint_auth_method: none). Never embed a client secret in browser or mobile code.

Managing what you registered

Revoke	Deactivates the client immediately — its tokens stop working and it can no longer authorise anyone. The registration stays visible.
Delete	Removes the registration permanently. Cannot be undone.

If a secret leaks

Revoke the client from Applications straight away — that invalidates its tokens.
Register a replacement, which issues a fresh client_id and secret.
Deploy the new credentials. Users are asked to re-authorise on next sign-in.

There is no way to rotate a secret in place. Because only a hash is stored, replacing the client is the only route — plan for that rather than assuming a rotate button exists.