Broadleaf’s Auth Service serves as both an extensible Authentication Provider and an Authorization Server. The Auth Service can be used by customers and admins to generate secure OAuth2 tokens (JWT) to access resource endpoints across various services. These Broadleaf JWT tokens work in conjunction with Broadleaf’s security model which uses a custom framework
@Policy annotation that allows for both role-based and ownership validation.
The sequence diagram below shows a simplified version of one the main OAuth2 flows (Authorization Grant) supported with Broadleaf’s Auth Service.
The silent authentication "handshake" requests are first initiated when a browser tries to load our Single Page Application (e.g. the
Broadleaf Unified Admin) and the application determines that the user is unauthorized. If so, the user is going to be re-directed to the Auth Service’s login screen.
User enters credentials and posts to the Auth Service
If successful, the JWT ID token (effectively the authentication) is set on a BLC specific cookie.
Using the authentication cookie, we will attempt to get an authorization code for the resources that user/application is asking for. The auth service performs validation to ensure user has access and permissions
The Auth Service issues an Authorization Grant code which the client application can then use to request an
AccessToken to the appropriate resource.
The system temporarily stores and removes this access code for one time retrieval and use when issued
Now that we have a valid
AccessToken, we can actually perform operations on the requested resource
Each of the key components is described in more detail in Key Components section.
See the Data Model for information on the key domain classes used by the auth service.
Several Example Customizations are provided such as creating custom token enhancers.