Managing OAuth Applications

OAuth applications are managed through the school admin UI. Pre-registered vendor platforms retrieve their credentials — rather than manage applications — via the client registration endpoint.

Admin UI

School administrators can manage OAuth applications at Settings > OAuth Applications.

Creating an application

1. Navigate to Settings > OAuth Applications
2. Click New Application
3. Fill in the application details:
   • Name — a descriptive name shown on the consent screen
   • Redirect URIs — one or more callback URLs (one per line)
   • Scopes — the permissions this application can request
   • Confidential — check this if your application can securely store a client secret
4. Click Create

After creation, you'll see the client_id and client_secret (if confidential). Store the secret securely — it cannot be retrieved later.

Editing an application

From the application list, click the application name to view its details. You can update the name, redirect URIs, and scopes. The client_id cannot be changed.

Revoking an application

Deleting an application immediately revokes all access tokens and refresh tokens issued to it. Users who authorized the application will need to re-authorize if a new application is created.

Client registration for vendor platforms

For automated integrations (such as MCP clients like Claude Code or Cursor), the registration endpoint issues credentials for pre-registered vendor platforms only: it matches your client_name against a known integration and returns that platform's credentials. It is not open dynamic client registration (RFC 7591) — an unrecognized client_name is refused with invalid_client_metadata.

POST /api/oauth/register
Content-Type: application/json

{
  "client_name": "Claude Code",
  "redirect_uris": ["http://127.0.0.1:41234/callback"],
  "grant_types": ["authorization_code", "refresh_token"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "none"
}

Known platforms

Loopwise recognizes the following client names and maps them to pre-registered platform applications. Loopwise's own internal clients are pre-registered too, but they answer to a fixed client ID rather than a name, so they never appear through this path and are not listed:

When a known platform registers, Loopwise returns the pre-registered application credentials for that platform. This ensures a consistent experience — users see the correct platform name on the consent screen.

An unrecognized client_name is refused with invalid_client_metadata; the endpoint does not register arbitrary clients. A client that is not a pre-registered vendor identifies via a Client ID Metadata Document instead — publish the document over HTTPS and use its URL as your client_id, where the server permits the document's host.

Discovery endpoint

Applications can discover OAuth configuration automatically via the well-known metadata endpoint:

GET /.well-known/oauth-authorization-server

This returns all endpoint URLs, supported scopes, and the default MCP client ID. See RFC 8414 for the full specification.