Kerberos UserIdentityTokens can be passed to the Server using the IssuedIdentityToken. The body of the token is an XML element that contains the WS-Security token as defined in the Kerberos Token Profile (Kerberos) specification.

Servers that support Kerberos authentication shall provide a UserTokenPolicy which specifies what version of the Kerberos Token Profile is being used, the Kerberos Realm and the Kerberos Principal Name for the Server. The Realm and Principal name are combined together with a simple syntax and placed in the issuerEndpointUri as shown in Table 37.

Table 37 – Kerberos UserTokenPolicy

Name	Description
tokenType	ISSUEDTOKEN_3
issuedTypeType	http://docs.oasis-open.org/wss/oasis-wss-kerberos-token-profile-1.1
issuerEndpointUri	A string with the form \\<realm>\<server principal name> where <realm> is the Kerberos realm name (e.g. Windows Domain); <server principal name> is the Kerberos principal name for the OPC UA Server.

The interface between the Client and Server applications and the Kerberos Authentication Service is application specific. The realm is the DomainName when using a Windows Domain controller as the Kerberos provider.

JSON Web Token (JWT) UserIdentityTokens can be passed to the Server using the IssuedIdentityToken. The body of the token is a string that contains the JWT as defined in RFC 7159.

Servers that support JWT authentication shall provide a UserTokenPolicy which specifies the Authorization Service which provides the token and the parameters needed to access that service. The parameters are specified by a JSON object specified as the issuerEndpointUrl. The contents of this JSON object are described in Table 39. The general UserTokenPolicy settings for JWT are defined in Table 38.

Table 38 – JWT UserTokenPolicy

Name	Description
tokenType	ISSUEDTOKEN_3
issuedTokenType	http://opcfoundation.org/UA/UserToken#JWT
issuerEndpointUrl	For JWTs this is a JSON object with fields defined in Table 39.

Table 39 – JWT IssuerEndpointUrl Definition

Name	Type	Description
IssuerEndpointUrl	JSON object	Specifies the parameters for a JWT UserIdentityToken.
ua:resourceId	String	The URI identifying the Server to the Authorization Service. If not specified, the Server’s ApplicationUri is used.
ua:authorityUrl	String	The base URL for the Authorization Service. This URL may be used to discover additional information about the authority. This field is equivalent to the “issuer” defined in OpenID-Discovery.
ua:authorityProfileUri	String	The profile that defines the interactions with the authority. If not specified, the URI is “http://opcfoundation.org/UA/Authorization#OAuth2”.
ua:tokenEndpoint	String	A path relative to the base URL used to request Access Tokens. This field is equivalent to the “token_endpoint” defined in OpenID-Discovery.
ua:authorizationEndpoint	String	A path relative to the base URL used to validate user credentials. This field is equivalent to the “authorization_endpoint” defined in OpenID-Discovery.
ua:requestTypes	JSON array String	The list of request types supported by the authority. The possible values depend on the authorityProfileUri. OPC 10000-7 specifies the default for each authority profile defined.
ua:scopes	JSON array String	A list of Scopes that are understood by the Server. If not specified, the Client may be able to access any Scope supported by the Authorization Service. This field is equivalent to the “scopes_supported” defined in OpenID-Discovery.

The OAuth2 Authorization Framework (see RFC 6749) provides a web based mechanism to request claims based Access Tokens from an Authorization Service (AS) that is supported by many major companies providing cloud infrastructure. These Access Tokens are passed to by a Client to a Server in a UserIdentityToken as described in OPC 10000-4.

The OpenID Connect specification (see OpenID) builds on the OAuth2 specification by defining the contents of the Access Tokens more strictly.

The OAuth2 specification supports a number of use cases (called ‘flows’) to handle different application requirements. The use cases that are relevant to OPC UA are discussed below.

The JSON Web Token is the Access Token format which this specification requires when using OAuth2. The JWT supports signatures using asymmetric cryptography which implies that Servers which accept the Access Token must have access to the Certificate used by the Authorization Service (AS). The OpenID Connect Discovery specification is implemented by many AS products and provides a mechanism to fetch the AS Certificate via an HTTP request. If the AS does not support the discovery specification, then the signing Certificate will have to be provided to the Server when the location of the AS is added to the Server configuration.

Access Tokens expire and all Servers should revoke any privileges granted to the Session when the Access Token expires. If the Server allows for anonymous users, the Server should allow the Session to stay open but treat it as an anonymous user. If the Server does not allow anonymous users, it should close the Session immediately.

Clients know when the Access Token will expire and should request a new the Access Token and call ActivateSession before the old Access Token expires.

The JWT format allows the Authorization Service to insert any number of fields. The mandatory fields are defined in RFC 7159. Some additional fields are defined in Table 40 (see RFC 7523).

Table 40 – Access Token Claims

Field	Description
sub	The subject for the token. Usually the client_id which identifies the Client. If returned from an Identity Provider it may be a unique identifier for the user.
aud	The audience for the token. Usually the resource_id which identifies for the Server or the Server ApplicationUri.
name	A human readable name for the Client application or user.
scp	A list of Scopes granted to the subject. Scopes apply to the Access Token and restrict how it may be used. Usually permissions or other restriction which limit access rights.
nonce	A nonce used to mitigate replay attacks. Shall be the value provided by the Client in the request.
groups	A list of groups which assigned to the subject. Usually a list of unique identifiers for platform specific security groups. For example, Azure AD user account groups may be returned in this claim.
roles	A list of roles which assigned to the subject. Roles apply to the requestor and described what the requestor can do with the resource. Usually a list of unique identifiers for roles known to the Authorization Service. These values are typically mapped to the Roles defined in OPC 10000-3.

The authorization code flow is available to Clients which allow interaction with a human user. The Client application displays a window with a web browser which sends an HTTP GET to the Identity Provider. When the human user enters credentials that the Identity Provider validates the Identity Provider returns an authorization code which is passed to the Authorization Service. The Authorization Service validates the code and returns an Access Token to the Client.

The complete flow is described in RFC 6749 Clause 4.1.

A requestType of “authorization_code” in the UserTokenPolicy (see 6.5.2) means the Authorization Service supports the authorization code flow.

The refresh token flow applies when a Client application has access to a refresh token returned in a previous response to an authorization code request. The refresh token allows applications to skip the step that requires human interaction with the Identity Provider. This flow is initiated when the Client sends the refresh token to Authorization Service which validates it and returns an Access Token. A Client that saves the refresh token for later use shall use encryption or other means to ensure the refresh token cannot be accessed by unauthorized parties.

The complete flow is described in RFC 6749 Clause 6.

A requestType is not defined since support for refresh token is determined by checking the response to an authorization code request.

The client credentials flow applies when a Client application cannot prompt a human user for input. This flow requires a secret know to the Authorization Service which the Client application can protect. This flow is initiated when the Client sends the client_secret to Authorization Service which validates it and returns an Access Token.

The complete flow is described in RFC 6749 Clause 4.4.

A requestType of “client_credentials” in the UserTokenPolicy (see 6.5.2) means the Authorization Service supports the client credentials flow.