The OAuth2 Authorization Framework (see RFC 5392) 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 a Server by a Client 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 document 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 may 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 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 8259. Some additional fields are defined in Table 52 (see RFC 7523).

Table 52 – Access Token Claims

Field	Description
sub	The subject for the token. Usually the RFC 7523 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 RFC 7523 resource_id which identifies 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 are assigned to the subject. Usually a list of unique identifiers for specific security groups. For example, Azure AD user account groups may be returned in this claim.
roles	A list of roles which are assigned to the subject. Roles apply to the requestor and describe what the requestor can do with the resource. Roles are list of unique names for roles.known to the Authorization Service. These values are typically mapped to the Roles defined in OPC 10000-3 using the identity mappings defined in OPC 10000-18.

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 5392, 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 5392, 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 5392, Clause 4.4.

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