CKR_USER_ALREADY_LOGGED_IN: login state is per token, not per session

Logging in applies to the token and to every session your process has open on it, so a second login for the same role is refused rather than repeated. That is harmless when the caller expects it and a puzzle when it does not, because the session that failed to log in is in fact logged in. Which code you get when the other role is the one logged in varies by library.

What the token is reporting

The token already has a user of this type authenticated, through this or another session in the process, and the library declined to log in again. As far as the token is concerned the session you called on is authenticated.

Likely causes

Ordered by how often they turn out to be the answer. That ordering is a judgement from experience, not a measured frequency.

Two components each logging in

The application and a provider it loaded both open sessions on the same token and both log in. The second gets this code, and if it treats the code as fatal it abandons a session that would have worked. Nothing is wrong with the token or the PIN.

Check it: Call C_GetSessionInfo on the session that failed. If the state is the user-functions state, the login already applied.

Fix: Treat the code as success. Login state is per token by design.

A retry loop that retries the login too

Wrappers that retry any failed call retry a login that succeeded on the first attempt but whose result was lost, or retry after an unrelated failure later in the same flow. Each retry earns this code.

Check it: Trace the login calls. Two logins with the same role and no logout between them is the pattern.

A session pool that logs in every session

Pools built on the assumption that login is per session log in each one as it is created. The first succeeds and every later one gets this code, which then either poisons the pool or is silently swallowed.

Check it: Count logins against tokens rather than against sessions.

Fix: Log in once per token, after the first session is opened, and tolerate this code from any later attempt.

The other role is logged in and the library files it here

The specification has a separate code for the case where a different user type holds the token, but some libraries and one vendor report it under this code. A user login while the security officer is logged in then looks like a duplicate rather than a conflict.

Check it: Read the session state. The SO-functions state with a user login failing means the roles are the problem.

Which calls return it

C_Login

What it is not

It is not a PIN problem and not a lockout. Several libraries check the login state before they look at the PIN, so a wrong PIN can hide behind this code until the earlier login is logged out.

Often confused with

CKR_USER_ANOTHER_ALREADY_LOGGED_IN: The code for the other role holding the token. Some libraries never return it and report both cases here.
CKR_USER_NOT_LOGGED_IN: The opposite state, and the one a failed retry loop produces once something logs out.
CKR_SESSION_READ_ONLY_EXISTS: What an SO login gets instead when a read-only session is open on the slot, before the login state is even consulted.

By library

SoftHSMv2

The token checks the other role first and reports it as another user logged in, then its own role as this code, and only then verifies the PIN (Token.cpp). A wrong PIN behind an existing login never surfaces. An SO login with a read-only session open on the slot is refused earlier still, with the read-only-exists code (SoftHSM.cpp).

Sources

PKCS #11 Specification Version 3.2, OASIS. Read 2026-09-10. Used for constant name and numeric value.

Every description, cause and check on this page is written from scratch. The specification is cited for the constant's name and its number, which are facts, and for nothing else.

`CKR_USER_ALREADY_LOGGED_IN`