Authentication concepts
Jutro provides two authentication clients - a native Okta client and a generic OpenID Connect (OIDC) authentication client.
Okta is an Identity Provider (IdP) that follows the OIDC standard and the native Okta client is built to support it specifically. You can use the generic OIDC client to authenticate with any other Identity Providers (IdPs) who support the OIDC standard.
The client supports authentication by default, but not authorization. However, you are free to implement authorization in your application. See the authorization section for more details.
OIDC concepts
OpenID Connect (OIDC) allows you to enable authentication for your application. It works in connection with an Identity Provider (IdP) that is responsible for authentication and authorization. The IdP is usually a third-party service that you need to configure and manage.
In short, your application redirects the user to the IdP login page. After successful authentication, the user is redirected back to your application with an authorization code. Your application then exchanges the authorization code for an access token and a refresh token. The access token is used to access protected resources, and the refresh token is used to renew the access token when it expires.
In OIDC, this process is called the Authorization Code Flow. You can learn more about OIDC and the Authorization Code Flow in the following articles:
Please note that in @jutro/auth
, Proof Key for Code Exchange (PKCE) is always enabled. You can learn more about PKCE in the following places:
The @jutro/auth
package provides two clients for use with OIDC IdPs - an Okta client for use with the Okta IdP and a generic client for use with any OIDC complaint IdP. These clients provide handy components, hooks, and functions which can speed up your implementation of authentication.
Authorization
Jutro itself does not perform user authorization. User authorization must be implemented through the Cloud API authorization configuration mechanism.
When a user is prompted to log in, they will be taken to Guidewire Hub for authentication. If successful, Guidewire Hub returns an encoded access token that is included in future requests to the Cloud API. The Cloud API uses this token to determine if the user is authorized to make the requests it receives.
For more information, see Configuring InsuranceSuite authorization groups in Jutro Web Apps and the authorization documentation for your InsuranceSuite App:
Example: Tailoring UI based on user permissions
Even though Jutro does not perform user authorization, you can still check a users permission and use this information practically. One use case is to determine what UI elements are shown or enabled. For example, disabling or hiding an input button if a user does not have a the post
permission. In a Jutro app, you have the following options for checking user permissions:
Checking HATEOAS links
You can the HATEOAS links in the Cloud API response to determine which actions are permitted for the user on a specific REST API resource. For example, a ClaimCenter response links section might look something like this:
"links": {
"assign": {
"href": "/common/v1/activities/xc:20/assign",
"methods": [
"post"
]
},
"notes": {
"href": "/common/v1/activities/xc:20/notes",
"methods": [
"get",
"post"
]
},
"self": {
"href": "/common/v1/activities/xc:20",
"methods": [
"get"
]
}
}
Using the Digital SDK
If you're using the Digital SDK, the HATEOAS links are parsed into a list of actions available to the user.
See the Actions overview section of the Digital SDK docs for more information about this feature.
Using the userInfo property
Depending on your Identity Provider (IdP), group information might be available within the userInfo
property of the useAuth
hook. If that's the case, you can utilize the userInfo
property to verify the groups to which the user belongs.
import { useAuth } from '@jutro/auth';
const { userInfo } = useAuth();
const groups = userInfo?.groups;
Was this page helpful?