We connect your application to other services and identity providers using OAuth 2.0, so access is granted without sharing passwords.

When your business system needs to send mail from Gmail, save files to OneDrive or read orders from a store, it needs permission. OAuth lets the account owner grant exactly the access needed, on the provider's own screen, and withdraw it later — without ever giving your software their password. Most of the connections on this site rely on it.

What we build with it

  • Delegated authorisation to a third-party service
  • Token-based API access
  • Scoped, revocable permission grants
  • OAuth-protected access to your own system's API for other applications

How it works

  1. A user clicks connect in your system, and is sent to the provider's sign-in and consent screen.
  2. The screen lists the permissions requested, and the user approves them.
  3. The provider returns a one-time code to your system, which exchanges it on the server for an access token and usually a refresh token.
  4. The system uses the access token to call the provider's API, and the refresh token to get new access tokens when they expire.
  5. If the user or administrator revokes access at the provider, the tokens stop working.

Data exchanged

  • Authorisation codes and access tokens
  • Granted scopes
  • Refresh tokens

What is needed to set it up

  • A registered client with the provider
  • Redirect URIs
  • Scope definition

Good to know

  • We request the narrowest scopes that do the job. Broad scopes worry users and can trigger extra review by providers such as Google.
  • Tokens are stored encrypted on the server and never exposed to the browser.
  • Mobile and single-page apps use the PKCE extension, which protects the code exchange where a secret cannot be kept.