Registration & limitations

Getting registered

Registration is a manual step performed by the Oase team — there is no self-service UI or API. Send Oase (hello@oase.app):

What	Example	Notes
oidc_client_id	0mc36k58amsgyk70msllhvkw1sidil8h	An identifier your login page recognises. Oase only echoes it back in the client_id query parameter — it carries no secret.
oidc_authentication_uri	https://app.partner.example/oauth	Your login page. Its hostname is what users see in the “log in with …” prompt.
scim_uri	https://api.partner.example/scim/me	Your SCIM user endpoint.

Oase will create the realm, register the provider on it, and hand back the realm’s join link. Do the same once more per extra environment (staging vs. production) — each realm has exactly one provider configuration.

Current limitations

• gzip is mandatory, not negotiated. An uncompressed SCIM response fails the sync.
• No token refresh. Once a user’s token is stored, Oase reuses it indefinitely; if it expires, that user’s sync silently stops (memberships freeze, access remains). Issue effectively non-expiring tokens or accept stale ones at the SCIM endpoint.
• The web login flow omits response_type (it sends only client_id and redirect_uri), so your login page must not require it.
• Pull-only, per-user propagation. Removals/renames on your side reach Oase only when an affected user’s app next syncs; there is no webhook for you to push changes and no batch or group-level sync.
• Photos are hot-linked. photos[].value is served to Oase clients as-is, so it must be an absolute URL reachable by end-user devices (long-lived, no auth). Relative paths do not resolve to anything.
• Empty-group cleanup is undefined. A mirrored group space whose group disappears is drained member-by-member as they sync, but the space itself is never deleted, and members who never open the app again are never removed.

Questions, or ready to get registered? Write to hello@oase.app.