Authentication screens

Native authentication components are UI for the flows exposed by @ovok/core. Mount them below OvokProvider, then let the host app handle navigation and presentation. The server remains responsible for identity, project membership, login policy, and access decisions.

For project configuration and flow prerequisites, start with Ovok authentication. Read access policies for what a signed-in user may access; hiding a screen in the app is not authorization.

Available components

Export	Use
SignIn	Composable email and social sign-in screen
Register	Registration screen and form
ResetPassword	Password recovery screen
ProfileForm	Profile editing form
LogoutButton	Sign out through the active client
DeleteAccountButton	Request account deletion through the active client
SessionList and useSession	Show sessions and manage revocation
useRateLimitCooldown	Read the cooldown state for a custom form

Sign-in form

import { SignIn } from '@ovok/native';

export function LoginScreen() {
  return (
    <SignIn>
      <SignIn.Header>
        <SignIn.Header.Title />
      </SignIn.Header>
      <SignIn.EmailForm
        loginType="Patient"
        tenantCode={tenantCode}
        onSuccess={handleAuthenticated}
        onError={handleError}
      >
        <SignIn.EmailForm.Inputs />
        <SignIn.EmailForm.SigninButton />
      </SignIn.EmailForm>
    </SignIn>
  );
}

onSuccess is the point to navigate or refresh app state. Keep onError connected to the app’s logging and user-message policy.

Multi-factor and registration steps

A password login can return a multi-factor step rather than a completed session. Use the form’s built-in verification field and do not navigate until authentication succeeds. Registration can also return a next step, such as an invitation flow. Handle the returned step explicitly; do not assume every registration response contains a session.

Registration availability depends on project settings and access-policy configuration. Review practitioner registration and the relevant settings before exposing the flow.

Social sign-in

Google and Apple sign-in require their native packages and build-time configuration. Keep provider secrets on a trusted server and expose only the app’s public client identifiers. Apple sign-in is available on iOS. Rebuild the native client after changing a config plugin.

Session and errors

The native UI does not replace backend session rules. Use the client’s session APIs for revocation and logout, and handle rate limits as a wait state rather than inviting rapid retries. Keep registration error messages neutral where the backend intentionally avoids disclosing whether an account exists.