The explicit use case means the Client provides the UserIdentityToken used to determine whether an Access Token is permitted and what claims are available in the call to RequestAccessToken. This use case is illustrated in Figure 31.

Figure 31 – Explicit Authorization

The Target Server is the Server that the Client wishes to access. It publishes a UserTokenPolicy that indicates that it accepts Access Tokens from an Authorization Server. The parameters needed to connect to the Authorization Server are stored in the IssuerEndpointUrl field of the UserTokenPolicy and are defined in OPC 10000-6. More details are described by the Implicit use case in 9.3.

With this use case, the Client reads the UserTokenPolicies Property of the AuthorizationService to determine what credentials to provide in the RequestAccessToken Method. The NodeId of the UserTokenPolicies Property is the ua:authorizationEndpoint field in the UserTokenPolicy provided by the Server (see OPC 10000-6).

The Session may be created explicitly with a call to CreateSession or it can be implicit via a Session-less Method Call.

After creating the Session, the Client reads the available UserTokenPolicies from the AuthorizationService Object if it has not previously cached the information. It then chooses one that matches credentials that it has been provided out-of-band. The Client then calls the RequestAccessToken Method on the AuthorizationService Object.

The Authorization Server determines if the Client is permitted to receive an Access Token. The rest of the interactions are the same as described in 9.3.