The OAuth2 Authorization Framework (see RFC 5392) provides a web based mechanism to request claims based Access Tokensfrom an Authorization Service(AS) that is supported by many major companies providing cloud infrastructure. These Access Tokens are passed to a Serverby a Clientin a UserIdentityTokenas described in OPC 10000-4.

The OpenID Connect specification (see OpenID) builds on the OAuth2 specification by defining the contents of the Access Tokensmore 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 Tokenformat which this document requires when using OAuth2. The JWT supports signatures using asymmetric cryptography which implies that Serverswhich accept the Access Tokenmust have access to the Certificateused by the Authorization Service(AS). The OpenID Connect Discovery specification is implemented by many AS products and provides a mechanism to fetch the AS Certificatevia an HTTP request. If the AS does not support the discovery specification, then the signing Certificatewill have to be provided to the Serverwhen the location of the AS is added to the Serverconfiguration.

Access Tokensexpire and all Serversshould revoke any privileges granted to the Sessionwhen the Access Tokenexpires. If the Serverallows for anonymous users, the Servermay allow the Sessionto stay open but treat it as an anonymous user. If the Serverdoes not allow anonymous users, it should close the Sessionimmediately.

Clientsknow when the Access Tokenwill expire and should request a new Access Tokenand call ActivateSessionbefore the old Access Tokenexpires.

The JWT format allows the Authorization Serviceto insert any number of fields. The mandatory fields are defined in RFC 8259. Some additional fields are defined in Table 49(see RFC 7523).

Table 49– Access Token Claims

Field

Description

sub

The subject for the token.

Usually the RFC 7523client_id which identifies the Client.

If returned from an Identity Providerit may be a unique identifier for the user.

aud

The audience for the token.

Usually the RFC 7523resource_id which identifies the Serveror the Server ApplicationUri.

name

A human readable name for the Clientapplication or user.

scp

A list of Scopesgranted 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 Clientin 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.

Usually a list of unique identifiers for roles known to the Authorization Service.

These values are typically mapped to the Rolesdefined in OPC 10000-3.

The authorization code flow is available to Clientswhich allow interaction with a human user. The Clientapplication 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 Providervalidates the Identity Providerreturns an authorization code which is passed to the Authorization Service. The Authorization Service validates the code and returns an Access Token to theClient.

The complete flow is described in RFC 5392, 4.1.

A requestTypeof “authorization_code” in the UserTokenPolicy(see 6.5.2) means the Authorization Servicesupports the authorization code flow.

The refresh token flow applies when a Clientapplication 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 Clientsends 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 requestTypeis 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 Clientapplication cannot prompt a human user for input. This flow requires a secret know to the Authorization Servicewhich the Clientapplication can protect. This flow is initiated when the Clientsends 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 requestTypeof “client_credentials” in the UserTokenPolicy(see 6.5.2) means the Authorization Servicesupports the client credentials flow.