Overview of authentication for unauthenticated callers

Typically, authentication includes credentials and authorization. However, unauthenticated callers have no credentials and have a limited set of default authorization.

Credentials

By definition, an unauthenticated user has no credentials.

Authorization

Endpoint access for unauthenticated callers

Endpoint access defines the aspects of an endpoint's behaviors that are available to a caller. This includes:

  • What endpoints and resource types are available to the caller?
  • What operations can a caller call on the available endpoint?
  • What fields can the caller specify in a request payload or get in a response payload?

Endpoint access is controlled by API roles. An API role is a list of endpoints, operations, and fields that are available to a set of callers through API calls. API roles act as allowlists. By default, a caller has no endpoint access. When the caller is associated with one or more API roles, they gain access to the endpoints, operations, and fields allowlisted in each of those API roles.

When an unauthenticated caller makes a Cloud API call, Cloud API automatically assigns them the Unauthenticated role. In the base configuration, this role provides two types of access:

  • Access to openapi.json endpoints
  • Access to POST to the /accounts, /accounts/*/contacts, and /accounts/*/locations endpoints. This is part of the authentication flow for anonymous users.
    • Note that these endpoints must be called in a single POST /accounts call that uses request inclusion for any contacts and locations. You cannot call the POST /accounts/*/contacts or POST /accounts/*/locations endpoints on their own.

For more information on how API roles are configured, see Endpoint access.

Resource access for unauthenticated callers

Resource access defines, for a given type of resource, which instances of that resources the caller can access. For example, suppose there is a GET /claims endpoint that is available to policyholders, underwriters, adjusters, and service vendors. All of these callers can use the endpoint to access resources whose type is claim, but none of the callers can access all of the claims. For example:

  • A policyholder may be able to see only the claims associated with the policies they hold.
  • An underwriter may be able to see only the claims for policies assigned to them.
  • An adjuster may be able to see only the claims assigned to them.
  • A service vendor may be able to see only the claims that have a service request assigned to them.

A resource access strategy is a set of logic that identifies the meaning of a resource access ID. Unauthenticated callers are automatically assigned the default resource access strategy. This strategy does not provide access to any business resources. It provides access to Cloud API metadata only.

Strategy name Persona using this strategy The resource access ID is assumed to be... Grants access to...
default Callers who have presented no resource access strategy Not applicable Metadata resources only (information returned by the various /openapi.​json endpoints)

For more information on how resource access behaves, see Resource access.

Proxy user access for unauthenticated callers

When a caller makes a Cloud API call, the internal PolicyCenter logic may trigger checks that are unrelated to endpoint access or resource access. For example:

  • A caller may attempt to assign an activity to themselves. PolicyCenter must check to see if the caller has sufficient permission to own an activity.
  • A caller may attempt to create a collision coverage with a deductible less than $1000. PolicyCenter must check to see if the amount of the coverage term is within the caller's authority limit.

Unauthenticated users are not listed in the PolicyCenter operational database, and therefore do not have any system permissions or authority limits tied to them. In the unlikely case that an unauthenticated user triggers an internal check, Cloud API makes use of proxy users. A proxy user is an internal user that is assigned to an external user or service when the API call is made. Whenever internal PolicyCenter logic must check to see if the caller has sufficient access, the proxy user is checked.

For more information on how proxy user access behaves, see Proxy user access.

JWTs for unauthenticated callers

An unauthenticated caller has no JWT. They are automatically assigned the Unauthenticated API role, and the default resource access strategy. In the base configuration, this provides access to API metadata only.

Logging

For each call, information about the caller is logged. The following table lists the fields that provide information about who the caller is, and where the logged value comes from.

Field Value
sub The value of the sub token claim from the JWT
clientId The value of the cid token claim from the JWT
user An empty string