> ## Documentation Index
> Fetch the complete documentation index at: https://docs.iru.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Credentials and sessions

> How Iru Identity protects the credentials users sign in with and the sessions they hold, and how to end access immediately when you need to.

Two things stand behind every user who reaches an app through Iru: the
**credential** they used to prove who they are, and the **session** that keeps
them signed in afterward. 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.

<CardGroup cols={2}>
  <Card title="The secret never leaves the user" icon="fingerprint">
    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.
  </Card>

  <Card title="Bound to Iru" icon="link">
    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.
  </Card>

  <Card title="Protected at rest" icon="lock">
    What Iru keeps to verify an authenticator is protected while it is
    stored, and is never enough on its own to impersonate the user.
  </Card>

  <Card title="Managed by users and administrators" icon="user-gear">
    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](/en/identity/directory/users).
  </Card>
</CardGroup>

<Info>
  Which authenticators users may register, and which a policy will accept
  for a given app, is up to you. See
  [Authenticators](/en/identity/authentication/authenticators) and
  [Authentication policies](/en/identity/authentication/authentication-policies).
</Info>

## 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.

<CardGroup cols={2}>
  <Card title="The app receives" icon="circle-check">
    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.
  </Card>

  <Card title="The app never receives" icon="circle-xmark">
    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.
  </Card>
</CardGroup>

<Note>
  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](/en/identity/applications/assigning-access).
</Note>

## How sessions are protected

After a successful sign-in, Iru establishes a session so the user isn't asked
to prove themselves again on every click. Sessions are protected so they can't
be borrowed or stretched indefinitely.

<AccordionGroup>
  <Accordion title="Sessions expire" icon="clock">
    A session does not last forever: it ends after a period of inactivity and
    again at a maximum age, after which the user signs in and the governing
    policy is evaluated afresh. The session length presented to a connected app is
    configurable per [SAML app](/en/identity/applications/saml-applications) and
    per [application role](/en/identity/applications/roles-and-bundles).
  </Accordion>

  <Accordion title="Each app sign-in is checked against policy" icon="shield-halved">
    Signing in to a connected app runs through that app's authentication policy,
    so a sensitive app can require a trusted device even when the user is
    already signed in to Iru. (A passkey or Iru Access is required for every
    sign-in either way.) See
    [Authentication policies](/en/identity/authentication/authentication-policies)
    and [Device trust](/en/identity/authentication/device-trust).
  </Accordion>

  <Accordion title="Sessions can be ended on demand" icon="right-from-bracket">
    A user's active sessions can be ended, which forces them to sign in again
    before they can continue. This is how you cut off access even when someone is
    already signed in.
  </Accordion>
</AccordionGroup>

## 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; each one is recorded in the
[activity log](/en/identity/administration/activity-log).

| Action                      | What it does                                                                                                     | Reversible?                                      |
| --------------------------- | ---------------------------------------------------------------------------------------------------------------- | ------------------------------------------------ |
| **End sessions**            | Ends the user's active sessions so they must sign in again.                                                      | Yes; they can sign in again if still active.     |
| **Suspend the user**        | Blocks all sign-in while preserving the record and history. Existing access is cut and new sign-ins are refused. | Yes; reinstating restores their previous status. |
| **Remove access to an app** | Revokes an assignment; for apps that support provisioning, the account there can be removed too.                 | Yes; reassign to restore.                        |
| **Remove the user**         | Deletes the directory record entirely.                                                                           | No; this cannot be undone.                       |

<Note>
  **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](/en/identity/applications/provisioning),
    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.
</Note>

<Warning>
  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](/en/identity/directory/users).
</Warning>

<Tip>
  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.
</Tip>

## 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

<CardGroup cols={2}>
  <Card title="Security and privacy" icon="shield-halved" href="/en/identity/security/security-and-privacy">
    The full security and privacy posture, expressed as plain guarantees.
  </Card>

  <Card title="Authenticators" icon="fingerprint" href="/en/identity/authentication/authenticators">
    Choose which authenticators users register and use.
  </Card>

  <Card title="The sign-in experience" icon="arrow-right-to-bracket" href="/en/identity/authentication/sign-in-experience">
    What users see when they sign in through Iru.
  </Card>

  <Card title="Users" icon="user" href="/en/identity/directory/users">
    Suspend, reinstate, reset authenticators, and manage users in your
    directory.
  </Card>
</CardGroup>