Skip to content
Oase Developers

The login page

When a realm member has not yet authenticated with your platform, the Oase app opens your login page in a browser (a system browser sheet on iOS/Android, a full redirect on the web):

GET {oidc_authentication_uri}
      ?client_id={oidc_client_id}
      &redirect_uri={redirect_uri}
      &response_type=id_token        <- sent by the native app flow
  • oidc_authentication_uri and oidc_client_id are the values you supply at registration time (see Registration).
  • On the web app the URL is built manually and carries only client_id and redirect_uri — do not require response_type, scope, state or nonce to be present.
  • The native flow uses an OIDC implicit-style request (response_type=id_token), so standard parameters like state may also be present; echo them back if your framework does, but Oase does not depend on them.

After authenticating the user, your page must redirect to redirect_uri with the token in an id_token (or token) parameter — query or fragment, the app parses both:

{redirect_uri}&id_token={token}

The redirect URIs to allow-list on your side:

Platform Redirect URI
iOS / Android oase://third_party/authenticate?oaseId={realm_id}
Web https://{app-origin}/third_party/authenticate?oaseId={realm_id}&andThen={url}

Note that the redirect URIs contain query parameters (oaseId, andThen): your redirect-URI validation must accept that, and you must append the token parameter to the existing query/fragment rather than replacing it — the app needs both oaseId and id_token present in the final redirect to complete the flow.

What the token needs to be (and not be)

Section titled “What the token needs to be (and not be)”

Oase treats the token as opaque. It is stored verbatim and replayed as Authorization: Bearer {token} against your SCIM endpoint. In particular, Oase does not:

  • validate a JWT signature, fetch a JWKS, or use OIDC discovery,
  • inspect any claims (sub, aud, exp, …),
  • run a token-exchange (code → token) flow — there is no token endpoint involved and no client secret.

So despite the “OIDC” label, the actual contract is: an implicit-style browser flow that hands the app an opaque bearer token which your own SCIM endpoint will accept. The token can be a JWT, a random session key, whatever — only you ever interpret it.