OAuth overview
RemyPass lets an external application sign members in using their RemyPass account. The member signs in on RemyPass, approves the connection, and returns to the application. The application receives a stable member identity and, when requested, profile, email and membership information.
Start with connection setup, then implement the authorisation code flow.
How sign-in works
- Your application redirects the browser to RemyPass with a client ID, registered callback, state and PKCE challenge.
- The member signs in with their portal password or emailed sign-in link and approves access.
- RemyPass redirects back with a single-use authorisation code and the original state.
- Your server validates state and exchanges the code using its client secret and PKCE verifier.
- Your server retrieves the member profile and signs the person into the linked account in your application.
The external application does not receive the member's RemyPass password.
Supported protocol
| Capability | Support |
|---|---|
| OAuth 2.0 grant | Authorisation code |
| Client type | Confidential application with a server-held secret |
| PKCE | Required, S256 only |
| Client authentication | HTTP Basic or form-body client credentials |
| Scopes | profile, email, membership |
| Profile endpoint | /api/v1/oauth/userinfo |
| Token format | Opaque Bearer token |
| Refresh tokens | Not supported; start a new authorisation flow |
| OpenID Connect | Not implemented: no openid, ID token, discovery or JWKS |
| Other grants | No password, implicit or client-credentials grant |
Applications that require OpenID Connect need a different integration. For an OAuth-compatible application, configure the endpoints explicitly and read identity from the profile endpoint.
Exact callback matching and PKCE follow the protections described in OAuth 2.0 Security Best Current Practice.
OAuth and the public API
| Use case | Authentication | Base path |
|---|---|---|
| Sign a member into another application | OAuth client credentials, then a member access token | /api/v1/oauth |
| Read or update organisation data from a backend integration | Organisation API key with endpoint permissions | /api/v1/public |
An API key authenticates an integration, not a member. OAuth tokens do not grant general access to the public API. Read API-key authentication for business data workflows.
Sessions and membership access
A connection can require an active membership or allow any active member account. RemyPass checks eligibility when access is approved, when the code is exchanged and whenever the profile endpoint is called.
Your application owns the session it creates after sign-in. Membership expiry or portal logout does not automatically log the member out of that separate application. Define when it checks eligibility again and when it requires a new RemyPass login.
Access tokens last ten minutes and there are no refresh tokens, long-lived eligibility tokens or cross-site logout notifications in this implementation. A new authorisation flow is needed after expiry; an existing RemyPass portal session can avoid another password entry, but the member still approves the connection.
See the endpoint reference for lifetimes, scopes and errors.