Developer authentication
How to add “Continue with StoatBoard” to your app
Last reviewed: By StoatBoard Editorial
StoatBoard is a community identity provider for applications that need a user-approved, bot-verified link to a Stoat account. The integration uses standard OAuth 2.0 and OpenID Connect, so your app never asks for or handles a user's Stoat session token.
Important distinction
Do not start from Add Bot
Add Bot publishes a bot in the public directory. To add sign-in to a website or SPA, create an application in the separate Developer Portal.
Before you start
- a StoatBoard account;
- a Web backend or browser-based SPA;
- a homepage, privacy policy, and optional support URL;
- at least one callback URL for local or production testing;
- a linked Stoat identity before testing the optional
stoatscope.
Set up the integration
Create a developer application
Open the Developer Portal and describe the product that users will authorize. Its name, exact domain, owner, privacy policy, and verification status are shown as trust context during consent.
Create the right client type
Choose Confidential Web when a backend can protect a client secret. Choose Public SPA for browser-only code: it receives no secret and no refresh token in v1. Native mobile clients are not supported in v1.
Register exact redirect URIs
Add every callback URI exactly as your application will send it. Production callbacks require HTTPS. Plain HTTP is accepted only for localhost, 127.0.0.1, and [::1] development callbacks.
Configure discovery and PKCE
Set the issuer to https://stoatboard.com and let a maintained OpenID Connect library discover the endpoints. Use Authorization Code with PKCE S256, plus a fresh state and nonce for every authorization request.
Request only the claims you need
openid is required. Add profile, stoat, email, or offline_access only when necessary. Email remains optional for the user, and an application must handle a reduced granted scope.
Test consent, callback, and revocation
Validate the returned state, exchange each code once, validate ID tokens through discovery and JWKS, and test denied consent, expired interactions, revoked access, and an account that has not linked Stoat yet.
What the user sees
- Your application redirects them to StoatBoard authorization.
- They sign in or create a normal StoatBoard account.
- They link Stoat through the bot proof if the requested identity is not linked yet.
- They review your exact domain, verification status, and requested permissions.
- After approval, StoatBoard returns them only to your pre-registered callback URI.
StoatBoard keeps the third-party return URI and OAuth state inside the provider interaction. Login, registration, email verification, and Stoat linking carry only an opaque internal interaction ID.
Expected result
Your application receives a stable opaque StoatBoard subject and only the scopes the user approved. With the stoat scope, it can receive the linked Stoat ID and verification state. It does not receive a Stoat credential or gain access to the user's Stoat session.