Sending authenticated calls for services with user context

When a caller application wants to make a Cloud API call for a service with user context, the caller application must:

Request a JWT from Guidewire Hub
Include the JWT (and the GW-User-Context header) with the system API call

Requesting codes and JWTs from Guidewire Hub

For more information on how to request JWTs from Guidewire Hub, refer to Authentication with Guidewire Identity Federation Hub in the Guidewire Cloud Platform documentation set.

Including JWTs with API calls

Once a JWT has been received from Guidewire Hub, it must be sent to BillingCenter in the request object's Authorization header. The header must use this format:

Authorization: Bearer <token>

Note: If a call includes a JWT with the bc.allowusercontext token claim, but the request object's header does not contain a user context header, Cloud API treats the call as if it were coming from a standalone service. In other words, the call will be restricted to the access provided to the service. No user-based restrictions are applied because there was no user context header specifying a user.

Authentication failure error messages

For endpoints that return an individual element, when the resource exists but the user lacks authorization to access it, Cloud API throws the following user message. This is the same message that is returned when the resource does not exist.

"status": 404,
        "errorCode": "gw.api.rest.exceptions.NotFoundException",
        "userMessage": "No resource was found at path <path>"

For endpoints that return collections, Cloud API returns all resources that meet the criteria and for which the user has sufficient resource access. If a resource exists, but the user lacks sufficient authorization, Cloud API omits it from the results.

These approaches are considered to be more secure as they prevent malicious callers from being able to verify the existence of data that they are not authorized to access.