Additional auth flows
Cloud API supports additional auth flows that do not make use of bearer token authentication:
| Auth flow | Definition |
|---|---|
| Basic authentication |
The caller is a person who is known to the insurer and listed as a user in the PolicyCenter database, such as a claims adjuster or underwriter. The call uses basic authentication (where auth information is passed in the request header) and not bearer token authentication (where auth information is passed in a JWT (JSON Web Token). Basic authentication can be an appropriate option for development environments, as it bypasses the new to have a working integration with Guidewire Hub or, when relevant, an IdP. |
| Anonymous user |
A person who is not yet known to the insurer, but who is interested in quoting and possibly binding a policy. The anonymous user flow involves at least two calls. In the first call, the user creates an account as an unauthenticated user. This call does not involve a JWT. PolicyCenter provides a self-signed JWT in the response to the first call. In the second call, the user presents the self-signed JWT. |
| Unauthenticated user |
The caller is a person or service who presents no authentication information. Typically, this type of caller is either a caller who accesses metadata only, or a caller who is creating an account as part of the process to become an anonymous user. Unauthenticated user access, when used by itself, can be appropriate for internal services that only need access to metadata, such as a service that is querying for the definition of an API. (Unauthenticated user access is also part of the anonymous auth flow.) |
The following table summarizes the issues to consider. It identifies the options for each issue, and which auth flow supports each option. The final row of the table provides a link which you can follow to get more detailed information about that auth flow.
| Basic Auth |
Anonymous User (PolicyCenter only) |
Unauthenticated User | |
|---|---|---|---|
| OAuth flow | not applicable |
not applicable as an anonymous user (Anonymous users who bind policies becomes external users, and from then on they use authorization code flow.) |
not applicable |
| Can each call have its own user attached to the session? | Yes |
No (For the first call, a single "unauthenticated proxy user" is used. For the second call, a single "external proxy user" is used.) |
No (a single "unauthenticated proxy user" is used for all relevant calls) |
| Where do authorization values come from? |
not applicable (no authorization values are passed within the auth flow) |
The first call includes no authorization values. For the second call, the authorization values are in the self-signed JWT provided by PolicyCenter. |
not applicable (no authorization values are provided) |
| Does Cloud API enforce resource access? | Yes | Yes | Yes |
| What do the resource access IDs come from? |
not applicable (no authorization values are passed within the auth flow) |
PolicyCenter |
not applicable (no authorization values are provided) |
| For more information on this auth flow | Basic authentication | OAuth2 authorization code flow: Anonymous users | Unauthenticated callers |