Skip to main content
Skip to content

Configure sign-in

Choose how your imported users will sign in to Owlie. Configure a login method, check that it matches the right identities, and prepare administrator recovery before removing any fallback. Importing an identity alone does not enable sign-in.

Decide who should be able to sign in​

A person can sign in only when all of the following are true:

  • Their Owlie identity is active.
  • The tenant has enabled a login method they can use.
  • The method can recognize them: for example, they have the applicable local credential, can receive a magic link, or can authenticate with an allowed external provider.
  • They satisfy any configured MFA and post-login requirements.

Your directory can also contain future hires, departed people, and service identities that do not sign in.

For a directory-backed rollout, use the same stable work email in the authoritative source and your identity provider. Correct mismatches in the source or Sync mapping before inviting users.

Choose the first method​

Open Admin > Tenant Settings > Authentication > Login methods. Changing these settings requires the tenant.login_methods.modify permission and may require you to verify your primary sign-in method again.

Owlie can offer Magic Link, Password, Secure Login (OPAQUE), Google SSO, Microsoft SSO, Okta SSO, Custom SSO, and SAML SSO when they are configured for the tenant. For a workforce already using an identity provider, start with that provider. These settings apply to the whole tenant, even while you are testing with a few users.

For an external provider:

  1. Enable its sign-in method and provide the credentials or metadata requested on the screen.
  2. Add every accepted value under Allowed Domains. A provider email outside this list is rejected.
  3. Enable Require verified email when the provider offers that setting.
  4. Leave Just-in-time provisioning off when your authoritative Sync already creates identities. This makes a missing Owlie identity a visible error instead of creating a second population.
  5. Select Save changes.

For SAML, use the displayed SP metadata URL, ACS URL, and SP entity ID to configure your identity provider, then enter its metadata or configuration in Owlie. SAML sign-in is service-provider initiated: begin the test from the Owlie sign-in page.

Keep a working fallback method during rollout. Password and Secure Login require a credential on the identity; merely enabling either method does not issue one. Magic Link requires email delivery to the identity's address. Password reset also does not convert an SSO-only user into a local user.

Understand first-login matching​

On the first external-provider login, Owlie checks the allowed domain and looks for an identity whose email matches the provider email without regard to letter case. Linking to that existing identity requires the provider to assert that the email is verified. After linking, Owlie recognizes the provider account on later sign-ins.

With Just-in-time provisioning off, a missing identity causes login to fail. A conflicting existing account link also needs administrator correction; Owlie does not silently move it to another person. Enable JIT only when the provider is intentionally another identity source.

Diagram placeholder: Imported identity to first sign-in. Show the active identity and enabled provider converging on an allowed, verified, case-insensitive email match; then show the persistent provider-account link used on later sign-ins. Include separate rejection branches for no match with JIT off and for a conflicting existing link.

Test without risking administrator access​

Use a private browser window and a non-administrator test identity from the imported population. Keep your current administrator session open while you test.

Confirm that:

  • the tenant sign-in page shows only the methods you intended to enable;
  • the provider accepts the test user and returns them to the correct Owlie tenant;
  • Admin > Directory still shows one identity for that person rather than a duplicate;
  • a user from an unlisted domain is rejected; and
  • when JIT is off, a provider user with no matching Owlie identity is rejected.

Complete any MFA or post-login steps that ordinary users will encounter. Repeat the test with a second account and prepare administrator recovery below before removing the fallback method.

Prepare administrator recovery​

Before moving to SSO-only sign-in, prepare recovery codes for at least two active administrators or owners. If the Login page shows a recovery warning, select Manage emergency recovery and have each administrator generate and securely store their own codes.

Each recovery code belongs to one identity. A valid code lets an active administrator or owner create a new Secure Password credential. It does not create a session, grant a role, or bypass the configured login journey. A code is single-use, so replace the recovery set after a real recovery event.

Once users can sign in reliably and administrators have a tested recovery path, continue to Connect your first provisionable target.