Skip to main content
Two things stand behind every user who reaches an app through Iru: the credential they used to prove who they are, and what Iru sends the app, which the app uses to keep them signed in. Here’s how Iru protects both, and how you cut someone off when you need to.

​
How credentials are protected

Users prove who they are with authenticators, and a passkey is the primary one. Passkeys are designed to resist phishing, which is the most common way credentials are stolen.

The secret never leaves the user

A passkey keeps the secret that proves identity bound to the user’s device. Signing in proves they hold it without ever transmitting the secret itself, so there is nothing reusable for an attacker to capture.

Bound to Iru

A passkey only works when the user is genuinely signing in to Iru. A look-alike phishing page cannot trigger it, because the passkey is tied to the real Iru sign-in and will not respond to an impostor.

Protected at rest

What Iru keeps to verify an authenticator is protected while it is stored, and is never enough on its own to impersonate the user.

Managed by users and administrators

Users manage their own authenticators in self-service. If someone loses access to theirs, an administrator can reset them so the user can register a new one. See Users.
Which authenticators users may register, and which a policy will accept for a given app, is up to you. See Authenticators and Authentication policies.

​
What an application receives (and what it never sees)

When a user reaches an app through Iru, the app learns who they are without ever learning how they proved it. This separation is what keeps a single stolen credential from spreading across your apps.

The app receives

A signed statement that confirms who the user is, plus the profile details you chose to map into that app’s sign-on. Because the statement is signed, the app can verify it really came from Iru and was not tampered with.

The app never receives

The user’s passkey or any other authenticator secret. Apps never hold the means to prove the user’s identity, so a breach of one app cannot be replayed against Iru or your other apps.
You decide which profile attributes are shared with each application, so an app sees only the details it needs to identify the user. See Assigning access.

​
How sessions are protected

After a user signs in to Iru itself, Iru keeps a session so they aren’t asked to prove themselves again on every click in Iru.
A session in Iru doesn’t last forever. An open Iru page renews it every two minutes, even if the user is idle. The session ends after 60 minutes without a renewal, or about 24 hours after sign-in.You set the session length a connected app receives per OIDC app, per SAML app, and per application role.
An Iru session never signs the user in to a connected app. Each app sign-in needs its own passkey, Iru Access, or identity-provider sign-in. Iru checks that sign-in against the app’s authentication policy, if it has one, so a sensitive app can require a trusted device even when the user is already signed in to Iru.Only Iru Access gives Iru device information. A sign-in with another passkey or through an identity provider can’t meet a policy. See Authentication policies and Device trust.
You can end a user’s active sessions, which forces them to sign in again before they can continue. Use this to cut off access while someone is already signed in.

​
Ending access immediately

When access needs to stop, you don’t have to wait for a session to expire. Pick the action that matches the situation. Iru records each one in the activity log.
Ending a session inside a connected app depends on the app. Ending sessions and suspending a user stop further sign-ins through Iru right away. Whether a user’s existing session inside a connected app also ends is up to that app and its protocol:
  • Apps that check with Iru on each access stop letting the user in at the next check.
  • For apps provisioned with SCIM, suspending or unassigning the user sends a deactivate (the account’s active flag set to false) or a delete to the app. Whether that immediately ends the app’s active sessions is determined by how the app handles that signal.
  • Some apps keep an existing session until it expires unless they support session revocation or single logout.
To cut someone off as completely as possible, suspend the user and end their sessions, and rely on each app’s deprovisioning to remove downstream access.
Suspending a user is the surest single action to cut someone off everywhere at once: it stops new sign-ins and existing access stays blocked until you reinstate them. Removing a user is permanent; suspend instead if there is any chance they will return or you need their history. See Users.
If you suspect a credential is compromised rather than the user, reset the user’s authenticators and end their sessions. They keep their account but must register a fresh authenticator before signing in again.

​
How a compromised credential is contained

The pieces above work together so that one stolen credential can’t cascade:
  1. Passkeys give attackers nothing reusable to phish in the first place.
  2. Apps never receive the means to prove identity, so a breached app can’t be replayed against Iru.
  3. If something does go wrong, suspending the user and ending their sessions cuts access immediately, and every step is recorded for review.

​
Where to go next

Security and privacy

The full security and privacy posture, expressed as plain guarantees.

Authenticators

Choose which authenticators users register and use.

The sign-in experience

What users see when they sign in through Iru.

Users

Suspend, reinstate, reset authenticators, and manage users in your directory.