UserIdentityToken
In OPC UA, a UserIdentityToken is the credential a client presents in ActivateSession to say who the user is, as distinct from which application is connecting. Four kinds exist: Anonymous, UserName with password, X509 user certificate, and IssuedToken for JWT, OAuth2, OIDC and similar external identity.
Application identity and user identity are different layers
The secure channel authenticates the application by its instance certificate. The session authenticates the user by an identity token. Both can be present, either can be weak, and confusing them is the root of most OPC UA access-control mistakes: a fully encrypted SignAndEncrypt channel with an Anonymous token tells you which software connected and nothing at all about who is behind the keyboard.
The four token types
AnonymousIdentityToken carries no credential. UserNameIdentityToken carries a username and a password that is encrypted with the channel's active security policy - so on a security-policy-None endpoint it is sent in clear. X509IdentityToken carries a user certificate plus a signature over the server nonce, proving possession of the private key, and is validated against the trustedUser and issuerUser stores rather than the application trust list. IssuedTokenIdentityToken carries an externally issued token, in practice a JWT from an OAuth2 or OIDC provider, whose issuer endpoint the server advertises.
What a client must check before choosing one
Each EndpointDescription lists the UserIdentityTokens it accepts, each with its own policy id, so the accepted token types differ per endpoint. Read that list rather than hard-coding. The refusal codes are worth distinguishing: BadIdentityTokenInvalid means the token was malformed or the type is not supported here, BadIdentityTokenRejected means it was well formed but not accepted, and BadUserAccessDenied means the user is known and not permitted. The first is a client bug, the third is a permissions question.
Changing user on an open session
ActivateSession can be called again on an existing session with a different token, which is how an HMI escalates from an operator to an engineer without dropping subscriptions. Not every server supports it, and the refusal is BadIdentityChangeNotSupported. Where it works, remember that the session's role assignment is re-evaluated, so monitored items the previous user could read may start returning BadUserAccessDenied rather than failing the whole session.
Example
The token list on an endpoint, and what each one actually proves
EndpointDescription opc.tcp://plc01:4840 SignAndEncrypt / Basic256Sha256
UserIdentityTokens:
Anonymous policyId "anon" proves: nothing about the user
UserName policyId "user" proves: knowledge of a password (encrypted by the channel)
Certificate policyId "cert" proves: possession of a user private key
validated against trustedUser/ and issuerUser/
IssuedToken policyId "jwt" proves: an external IdP asserted this identity
server advertises the IssuerEndpointUrlDefined in: Part 4 - Services, ActivateSession and identity tokens; Part 2 - Security Model.
Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.