OAuth Overview

Loopwise uses OAuth 2.0 to allow third-party applications to access school data on behalf of users. This page explains the key concepts.

Why OAuth?

OAuth lets users grant limited access to their Loopwise data without sharing their password. An integration (the "client") receives an access token with specific scopes that define exactly what it can do.

Benefits:

• Security — users never share their credentials with third-party apps
• Granular access — scopes limit what data an integration can access
• Revocable — users or admins can revoke access at any time without changing passwords
• Auditable — each integration has its own identity, making it easy to track who accessed what

Architecture

Each school operates as an independent OAuth provider. When you create an OAuth application in a school's admin panel, it is scoped exclusively to that school.

The token issued by School A can only access School A's data. There is no cross-school access.

Key concepts

Authorization server

Each school acts as its own OAuth authorization server. It authenticates users, presents the consent screen, issues authorization codes, and exchanges them for access tokens.

A school's OAuth endpoints are accessible at https://{school-subdomain}.loopwise.com.

Client application

The third-party integration that wants to access a school's data. Clients are identified by a client_id and optionally a client_secret (for confidential clients). Each client is registered within a specific school and can only access that school's resources.

Resource owner

The user (typically a school admin) who authorizes the client to access data. The authorization grants access to the school where the OAuth application was registered.

Access token

A short-lived credential (2 hours) that the client uses to make API requests. Tokens are scoped to the school where the OAuth application was created, along with a set of permissions.

Refresh token

A long-lived credential used to obtain new access tokens without requiring the user to re-authorize.

Supported flows

Loopwise supports the Authorization Code flow with PKCE (Proof Key for Code Exchange, RFC 7636). This is the recommended flow for all clients, including public clients (SPAs, native apps, CLI tools).

For a detailed walkthrough of the flow, see Authorization Code Flow.

School scoping

Each OAuth application belongs to exactly one school. When an admin creates an OAuth application in their school's settings, the application is permanently bound to that school:

• The issued client_id only works with that school's authorization endpoint
• All tokens carry the school's school_id and are validated against it
• The token response includes school_id and school_subdomain for the client's reference

This design ensures strict tenant isolation — an OAuth application created for School A can never be used to access School B's data.

MCP clients

Loopwise also supports Model Context Protocol (MCP) clients such as Claude Code and Cursor. These are platform-level integrations that use the same OAuth 2.0 protocol but work differently from school-scoped applications:

• MCP clients are registered as system-default applications across the platform
• During authorization, the user selects which school to grant access to
• Each authorization produces a token scoped to the selected school

If you are building a standard integration for a specific school, you do not need to worry about MCP — simply register your application in the school's admin panel.

IP allowlisting

For enhanced security, we recommend allowlisting the following IP address in your firewall or reverse proxy:

52.194.91.27

This is the IP address from which Loopwise makes outbound requests (webhooks, callbacks).