Authentication

The Auth Service serves as an Authentication Provider built on top of core Spring Security OAuth2 functionality. The default implementation follows basic OIDC-like principles to allow support for concepts like silent authentication flows and identity token support.

The authentication service is built to be highly extensible. It supports both SSO and non-SSO flows. The service itself ships with pre-built login pages that can be easily styled to support custom templates. Additionally, the backing authentication mechanisms can be integrated with external services using typical Spring Boot OAuth 2 configuration patterns.

Those already familiar with Spring Security OAuth and Open ID Connect integrations will feel comfortable working within the patterns and flows implemented within Broadleaf’s Auth Service

Broadleaf uses Centralized Universal Login by default and recommends this for users. This means that the Auth Microservice hosts the login, registration, change password, and reset password forms. Thus, users of the commerce or admin apps will be redirected to the Auth service to perform these operations; then redirected back upon completion.

Embedded login means that the commerce or admin app would host its own forms and submit the data to the Auth server. The user would not be redirected anywhere. While this may seem better from a user-experience perspective, it is less secure. Auth0 discusses this in more depth.

However, if the need is strong enough to use embedded login for web apps, they may be enabled with little configuration. Moreover, the default deployment of microservices recommended by broadleaf would allow cross-origin requests to be locked down since all microservices along with the frontend apps are run behind the same gateway, which is the greatest source of risk with embedded login.

To enable embedded login in general for the system, set broadleaf.auth.login.embedded.enabled to true. Then, set embeddedLoginEnabled to true on each individual AuthorizationServer where this feature is desired. This allows the admin to still use Universal Login while a commerce app could use embedded since each will have their own AuthorizationServers.