The Authentication Model

How login and identity verification works in octoja

Written By Erdinc Akay

Last updated 17 days ago

octoja supports three verified sign-in patterns today: local password login, password plus TOTP, and OIDC / SSO.

Authentication methods

Method	How it works	Best for
Password	Email address plus password	Smaller teams or local-only setups
TOTP (2FA)	A code from an authenticator app, requested after your password or after SSO sign-in	Stronger protection for any sign-in, local or SSO
SSO (OIDC)	Sign in through a configured identity provider such as Microsoft	Organisations that already manage identities centrally

Important behavior

A user without a password cannot use local password login.
Passwordless access depends on a linked OIDC / SSO provider.
For Microsoft SSO, the first sign-in may require a Microsoft administrator to grant tenant consent for octoja.

Recommended setup

TOTP adds meaningful protection to any sign-in: if a user has 2FA enabled, signing in through an identity provider now also prompts for the authenticator code, so SSO logins are covered as well as local password logins. Organisations that want central identity management and passwordless sign-in are best served by Microsoft or another OIDC provider. Authentication only verifies identity. What a user can then see and do is governed separately by the groups they belong to — a group grants module permissions, Customer Access (which customers members can work with), and Device Access with its Allowed actions (which devices members can reach and what they may do on them). See Users, Groups & Permissions.

Session management

Browser-based sign-ins use a session cookie managed by octoja.
API clients use bearer tokens returned by the login or refresh endpoints.
Logging out ends the current browser session.

See also: API Authentication, Reset Your Password