Accounts and authentication
Use this guide to choose an account flow and understand what to configure before you add it to an application. @ovok/core provides client methods and typed results; your application provides the screens, navigation, and user feedback.
Choose a flow
| Goal | SDK method | Guide |
|---|---|---|
| Sign in a patient or practitioner | login() | Sign in |
| Register a patient | register() | Registration |
| Sign in with Google or Apple | googleLogin() or appleLogin() | Social sign-in |
| Change or reset a password, or manage sessions | changePassword(), resetPassword(), getSessions(), and related methods | Passwords and sessions |
| Schedule account deletion | requestDeleteUser() | Account deletion |
The SDK's register() method is for patient registration. Practitioner onboarding is configured separately; use the platform's practitioner registration guide or invitation flow.
Before you add an account flow
Confirm the project and tenant
Patient sign-in and registration target a tenant. Practitioner accounts can belong to multiple projects, so the application needs to know which project the practitioner should enter. Review project setup and keep the tenant code with the matching environment configuration.
Check the project settings
The project controls which sign-in and registration flows are available. Review the authentication overview, then confirm the relevant settings:
Registration also depends on a project AccessPolicy for new accounts. Read the AccessPolicy guide and the project setup steps before enabling registration.
Build the application flow around the result
Sign-in may require an additional multi-factor authentication step. Registration can sign a user in immediately. Session and password operations return different outcomes, so handle success, pending steps, and errors in the screen that started the operation. The SDK does not provide a finished login or account-management interface.
Manage saved accounts
getSavedAccounts() returns the accounts available to this client without exposing access or refresh tokens. Use switchAccount(accountId) to open a saved account. If its refresh token is refused, the account remains listed with expired: true and the previous account is restored; ask the person to sign in again rather than retrying the saved session. If the selected account was activated but its profile could not be refreshed because the device is offline, the switch resolves with that account active and the session offline. A temporary network or server error does not mark the account expired.
removeAccount(accountId) ends the selected account's server session before removing it locally. If the server confirms that the session has already ended, the SDK removes the saved account locally. A network or server failure keeps it available so the app can offer a retry. Removing an inactive account restores the previous active account; removing the active account selects only another listed, non-expired account. If there was no active account, removal does not activate one.
logout() is different: it always clears the active session and removes that account from this device's saved list, even when the server cannot be reached. In that offline case, the server-side session may remain valid until it expires, but this client no longer has the saved login. See sign out for details.
SDK guides
- Sign in — patient and practitioner sign-in, tenant selection, and MFA.
- Registration — patient self-registration and platform prerequisites.
- Social sign-in — Google and Apple provider results and configuration.
- Passwords and sessions — password changes, recovery, logout, and session revocation.
- Account deletion — schedule account deletion and choose how related medical data is handled.