A note from 2026: This article was published in 2019. SAP Commerce Cloud Accelerator/JSP storefronts and the examples around j_spring_security_check are now legacy patterns; new projects more commonly use SAP Composable Storefront and external identity providers, while the security principles still apply.

Rauf Aliev

When it comes to your overall website usability and providing a good user experience to your site visitors, the login component plays a very important role. This article explains how it should be built to provide the best customer experience.

The topic is purposely narrow. I focus on how to implement login forms and the authentication process in e-commerce systems built on top of SAP Commerce Cloud. In fact, the general recommendations and findings are applicable to other platforms too.

What makes a good sign-in experience for your customers? There are two pillars: good security and good user experience. Backed by the platform and Accelerator built-in features, many developers and product owners prefer to minimize the number of customizations and stick with out-of-the-box functionality. This strategy works well only if you need to release your product in the shortest possible time.

From the authentication perspective, best practices recommend offering users the ability to check out as a guest and/or forcing or inviting them to register before completing the purchase or after it. Fundamentally, customer authentication is important for the next visits of a customer. Very often, customers don’t see any benefits of being authenticated. Many of them prefer to check out as guests and minimize the information they share about themselves. That is why it is becoming more and more important for merchants to respect and protect customer data.

For B2C websites, forcing users to register first may lead to a decrease in conversion rates because it breaks the buying process. In B2B solutions, it is a primary and widely used option because guest users are normally not involved in the B2B process at all.

The login form is a very important piece of the interface, and implementing it properly is crucial for success.

You may ask: how can one make a mistake in such a simple thing? In this research, I analyzed different implementations and technologies, common mistakes, and strategies.

This article is the third in a series. Please find the other two if you are interested in the broader area:

Overview {#Overview}

Session Handling Methods Used with Authentication {#SessionHandling}

Let’s start with a short overview of authentication methods from the perspective of session handling methods on the Web.

Session-based authentication (stateful) {#SessionBased}

A session is defined as the time during which a user is actively logged onto a server with a cookie. So, session-based authentication is one in which the user state is stored in the server’s memory. That is why it is also called stateful.

The typical flow is the following:

Session-based authentication flow

The advantages of this approach are:

However, this approach doesn’t work well for a very large number of concurrent sessions. As the number of logged-in users increases, you need more and more server resources. Scaling and distributing the sessions over a cluster introduce new challenges, such as supporting sticky or distributed session management. This type of authentication has been elaborated well, and there is a solution for every case, but every complication creates a bunch of new challenges.

SAP Commerce Cloud uses session-based authentication for customer sign-in and session management.

Token-based authentication (stateless) {#TokenBased}

Token-based authentication is used to address the disadvantages of session-based authentication. In brief, in token-based authentication, the user session data is stored on the client side, in the browser. This data is signed by the key of the IdP to ensure the integrity and authority of the session data.

The process is the following:

Token-based authentication flow

The session data is effectively distributed in this option. It allows storing more information about the user on the client side. Token generation is decoupled from token verification. It allows you to handle the signing of tokens on a separate server or service.

However, you can’t revoke the session easily in token-based authentication. Changing user data is challenging too. For example, you may want to add a new user session property. All new sessions will take this property, but existing sessions will keep sending the obsolete set until the session is re-established.

In SAP Commerce Cloud, token-based authentication is not used.

Authentication methods {#AuthMethods}

The methods explained below can be used in different combinations. When the user is authenticated, the server initiates a session using the approaches explained above.

Certificate-Based Authentication {#CertificateBased}

This authentication method is based on SSL certificates.

Certificate-based authentication flow

Password-based authentication {#PasswordBased}

This authentication method is based on the “secret” pair of the login and password.

Password-based authentication flow

Passwordless authentication {#Passwordless}

In passwordless authentication, the user’s identity is verified without asking the user to provide a password. For this method, it is implied that only the user has access to a personal physical device that is uniquely addressable and can communicate securely with the server over a distinct communications channel, referred to as the secondary channel.

Passwordless authentication flow

Authentication stacking methods {#AuthStaking}

Single Factor Authentication (SFA) {#SingleFactor}

The most common form of this authentication is the password-based authentication explained above.

Two Factor Authentication (2FA) {#TwoFactor}

Two-factor authentication, also called two-step verification, is an upgrade to password-based authentication by adding an extra step to the sign-in process: the second factor.

The most common form of two-factor authentication is mixing password-based authentication with a passwordless approach using SMS services. This assumes that the user has a personal device, a mobile phone, nearby each time the system requests a second verification.

Multi-Factor Authentication {#MultiFactor}

With this method, the authentication credentials are combined from:

Authentication in distributed systems {#AuthDistributed}

Single Sign-On (SSO) {#SSO}

The idea of Single Sign-On describes the ability to use single authentication to gain access to a number of websites. The products authenticate users in a single location and then create tokens that can be used by downstream web applications for authorization.

In this method, there is a central service that orchestrates the single sign-on between multiple clients. When a user first logs in, the central service creates a token, which persists with the user as they navigate to the various websites integrated with the same SSO service.

Social Sign-in is a form of SSO using existing account information from social networks such as Facebook, Twitter, or Google+ to sign in to a third-party website instead of creating a new account specifically for that website.

There is no SSO implementation for customers in the default SAP Commerce Cloud. The OOTB support of SAML-based SSO was designed for Backoffice users. The extension for that is provided with Commerce Cloud.

By the way, I published an article on Okta/hybris integration to support customer SSO: /2016/06/15/hybrisokta-sso-integration/

Implementation {#Implementation}

Login Form in SAP Commerce {#LoginForm}

The default login form is very basic in the default SAP Commerce. It contains three essential form controls:

The form action is /j_spring_security_check. This login processing URL is specified in the configuration.

There is also a link to “Forgotten password.” The form doesn’t contain a “Remember Me” link.

Recommendations:

Authentication Flow in SAP Commerce Cloud {#AuthFlow}

The default SAP Commerce storefront is built on top of JavaServer Pages and the Spring Framework. Almost everything the developer should care about in login forms, authentication, and system activity authorization involves Spring Security. SAP Commerce comes as a preconfigured solution implementing a common scenario of customer authentication.

For the sake of consistency, let’s review the basic authentication flow.

In the SAP Accelerator, /login is configured as a login page URL. The website has a number of protected pages, listed in the configuration. When an anonymous user attempts to access the protected page, and Spring Security finds the user is not authenticated, the system redirects them to the login page to be logged in. Of course, the login page can be accessed directly by visiting /login, a link behind the “Sign in” button.

With the first request to the server, the system initiates a session. The session is stored on the application server level. The application server, Apache Tomcat, sends the unique identifier of the session back to the browser. This unique identifier is a 26-character hash key into the server’s map of active sessions. This key is stored in JSESSIONID.

On the login page, the user is challenged to provide login credentials. When the form is submitted, the server verifies the login and hashed password against the database. If a match is found, the system saves the information into the HTTP session and returns an acceleratorSecureGUID cookie with a random value. This cookie carries the information that the customer is logged in.

Next time the user requests a page, the browser will send JSESSIONID and acceleratorSecureGUID in the request header, so the server will be able to identify the session, extract acceleratorSecureGUID from the session, and compare the value with the one received with the request. If there is a match, the system will check whether the logged-in user from the session has enough permissions to get to the page. Session parameters, such as session variables, are used to store the session user parameters.

The login processing URL is specified in the configuration. By default, it is /j_spring_security_check. This URL is mapped to UsernamePasswordAuthenticationFilter to serve the requests. There are two parameters for the filter used from the form. In the SAP Commerce configuration, these are j_username and j_password. Depending on the authentication status, the Spring Framework executes one of two methods:

For logging out, there is a dedicated URL, /logout. It is mapped to StorefrontLogoutSuccessHandler. When logging out from a restricted page, the user is returned to a home page.

Read more on Spring Security in SAP Commerce: https://help.sap.com/viewer/4c33bf189ab9409e84e589295c36d96e/1811/en-US/8aef3efe8669101481a0ffe871a2f84c.html

Remaining Logged In / Remember Me {#RememberMe}

The concept of the “remember me” feature is that the authenticated state is persisted beyond the immediate scope of use. Customers can close the browser, turn off their PC, then come back later, and the web shop still knows who they are and offers them all the same features they had when they left it. In the login form, this functionality is represented by the “Keep me logged in” checkbox.

In SAP Commerce Cloud, the default login form doesn’t have a “remember me” checkbox, but the functionality is present and on by default. The Accelerator storefronts support the “Soft Login” concept, which automatically logs a customer into the storefront based on a *rememberMe cookie, for example, yb2bacceleratorstorefrontRememberMe for the OOTB B2B. It uses the Spring TokenBasedRememberMeServices implementation.

After the user is logged in, the system sends this *rememberMe cookie to the browser, and the value of the cookie contains a username along with the hashed password and some other information. When the session is over, the authentication mechanism will use the rememberMe cookie to re-authenticate the customer automatically. The rememberMe cookie is Base64-encoded, so the username is extracted easily using a Base64 decoder.

The rememberMe cookie-based authentication is called “soft” to distinguish it from hard authentication based on the password. A softly authenticated customer needs to provide a password and log in fully to access account-related functionality or proceed through checkout.

Signing out removes the rememberMe cookie completely from the browser.

More details on j_spring_security_check implementation in hybris {#MoreDetails}

The login and password are sent as POST to:

/<storefrontcontext>/powertools/en/USD/j_spring_security_check

The SAP Commerce Cloud Spring configuration tells us that /j_spring_security_check is mapped to springSecurityFilterChain.

There are tens of standard storefront filters processed. I would like to feature some of them that are important in our context:

Csrf Filter {#CsrfFilter}

The filter checks if the URL is in the list of URLs where the CSRF check shouldn’t be involved. The property names csrf.allowed.url.patterns and csrfAllowedUrlPatternsList specify URL patterns that allow you to bypass CSRF token validation. These URLs are the ones ending with …sop/response, …merchant_callback, …hop/response, …language, and …currency. Since /j_spring_security_check is not in the list, the system compares the value from the HTTP session and a value from the form. If they are different or the CSRF token is not present, the system stops the request processing with the corresponding exception.

Logout Filter {#LogoutFilter}

This filter performs logout for the user if the request URL matches the particular pattern, /logout by default.

Authentication Processing filter {#AuthProcFilter}

This filter intercepts the authentication URL processing. By default, it is j_spring_security_check. For username and password mode, it retrieves the credentials from the form data and passes them through the authentication provider, which performs the following checks:

These checks are provided by the B2B Accelerator Authentication Provider, the B2B Accelerator add-on, and the Core Authentication Provider, the platform core.

Abstract Accelerator Authentication Provider increments the counter of failed attempts and disables the account after the configured number of attempts, providing brute-force attack protection.

RememberMe Authentication Filter {#RememberMeFilter}

The concept of RememberMe has been explained above. The filter is responsible for activating the feature in the solution.

This filter is part of the Spring Framework. SAP Commerce uses it as is but configures the filter with a custom RememberMe Services class, AcceleratorRememberMeServices.

When a registered user logs in to the storefront, a <storefront>RememberMe cookie is created by the Remember Me services to identify the user. When the user logs out, this cookie is cleared out. However, if an authenticated user closes their browser without logging out, and the user attempts to visit a specific page in the storefront again, when the request is made for this secure resource, the RememberMe Authentication Filter injects the RememberMe authentication token into the session when loading the storefront.

Anonymous Authentication Filter {#AnonymousFilter}

This is a Spring Framework filter. It creates a filter with a principal named anonymousUser and the single authority ROLE_ANONYMOUS. SAP Commerce uses it as is.

Importance of HTTPS {#https}

Possibly, this topic may seem trivial, but when you start scratching the surface, there are a lot of important details to learn.

For the login form, HTTPS is a must. Otherwise, your password will be sent in clear text. It means that anyone eavesdropping on the line between you and the server will be able to intercept and read your password. This technology is called wiretapping or packet sniffing. So, if the line between the user and server is unencrypted, everything you do is vulnerable to man-in-the-middle attacks. The only protection is using a certificate-based secure connection.

It’s not enough to submit the login form over HTTPS. It is very important to deliver the form itself over HTTPS too. If the login form is delivered over a non-secure channel, someone “in the middle” between you and the server can inject JavaScript code, such as a keylogger, to steal the credentials by sending everything you type in the form or changing the form submission location. There is no easy way to protect against keyloggers, so it is better to follow the recommendations and encrypt the login form to make this attack impossible.

Additionally, Google Chrome and Firefox have already marked non-secure pages containing password input fields as Not Secure in the URL bar. Additionally, HTTPS is a confirmed Google ranking factor: secure websites are higher in the search results.

That is why SAP Commerce Cloud default settings include preconfigured HTTPS. By default, SAP Commerce Accelerator secures all storefront pages using HTTPS. Previous versions of the Accelerator only secured the Checkout and My Account pages using HTTPS.

In production setups, SSL is highly recommended to terminate at the load balancer level. It is not only convenient, because you can manage certificates centrally, but also offers a centralized place to correct SSL attacks, such as CRIME (https://en.wikipedia.org/wiki/CRIME). Terminating SSL at a variety of web servers running on different operating systems will likely run you into problems due to the additional complexity. So, the best practice is having an SSL-enabled load balancer and a non-HTTPS SAP Commerce app.

Feedback Messages {#FeedbackMessages}

If the user enters all data correctly and gets logged in, the redirect happens on the server side to the requested page or a default after-login page. It is a good practice to show a success message at the top of the page so the customer knows immediately that the login was successful.

As for form validation during input, it is a good practice to show an error message if:

For the failed login attempt, the application might respond with the reason, such as an incorrect password or unrecognized username. This behavior might look like a good intention to help users understand what was wrong. However, it is not recommended: an attacker can use it to iterate through a list of common usernames to find valid ones. This list can be used for various attacks, including password guessing, attacks on user data or sessions, or social engineering. That brings us to brute-force attack protection.

If the account is locked or the validity period is over, show the relevant message with instructions on what to do to make it live again.

Password Strength {#Passwords}

Although checking password strength is a little bit off topic, because it is related to the registration form rather than to the sign-in process, I’ve decided to add it to my overview because it is rather important.

Implementing a good authentication mechanism based on passwords is challenging. Users’ safety heavily relies on how they create their passwords. Their passwords could be weak, forgotten, reused, or stolen. According to Google, during a period of just one year, the data breach exposed a total of 1.9 billion usernames and passwords.

If minimum strength requirements are not part of your password policy, you will have about 2% of users who use one of the top 20 most common passwords. It means that if an attacker gets just 20 attempts, one in fifty accounts on your website will be crackable.

Recommendations:

More information:

Brute Force Attack Protection {#BruteForceProtection}

A brute-force attack is an attempt to discover user credentials by automatically and systematically trying different combinations of usernames and passwords with the intent to discover the one correct combination that works. This attack uses dictionary words or lists of common combinations. Besides putting your users at risk, this attack floods the website with unnecessary traffic.

So there are two sides to the problem:

For the second goal, first and foremost, enforce strong passwords for all users, and a brute-force attack will not succeed. Brute-force attacks can be stopped before the requests reach the application server. The solutions for that are often provided by cloud hosting providers.

There are a number of techniques for preventing brute-force attacks.

The simplest and most obvious way to block such attacks is locking out accounts after a defined number of incorrect password attempts. This is exactly how it is implemented in the default SAP Commerce. Such a policy can give rise to further vulnerabilities. An attacker is able to lock out real accounts. It will deny access to a system for many accounts and flood the help desk with support calls. Additionally, an attacker can use this fact to harvest usernames from the website, depending on the error responses. Once the account is unblocked, the attacker can block it again, effectively disabling the account. Marking the accounts as blocked repeatedly can result in a lot of write processes, which can be another performance bottleneck. User lockout is ineffective against slow attacks when only a few combinations are tried every hour. It is also ineffective for attacks when the same password is tried with a combination of thousands of usernames. So, account locking is bad and not a practical solution at all, but it can be efficient for simple cases only.

Another protection, or rather a sort of complication for the attacker, that SAP Commerce Cloud has is Anti Cross-Site Request Forgery, or anti-CSRF, tokens, also called request verification tokens. SAP Commerce Cloud protects the login form with an anti-CSRF token out of the box. The server includes two tokens in the response for the form. One token is sent as a cookie. The other is placed in a hidden form field named CSRFToken in SAP Commerce. The tokens are generated randomly. When the customer submits the login form, it sends these tokens back to the server. The client sends the cookie token as a cookie, and it sends the form token inside the form data. The server validates the pair, and if they don’t match, it throws a CSRF error. So, there is nothing preventing the attacker from repeatedly visiting the login page and getting a new, valid anti-CSRF token each time.

There are different solutions for that, but all of them have the same problem: during design and development, stakeholders often don’t consider the risks of brute-force attacks important.

Another problem is that many known solutions are efficient only against simple attacks and non-dedicated attackers.

Identifying and locking IP addresses with multiple failed logins may look efficient at first glance, but in fact, it has its flaws too: you can inadvertently block large corporations that use the same proxy server for all their employees, your customers. Even a simple CAPTCHA is effective, but bear in mind that CAPTCHAs slow down the customer experience and affect conversion negatively. Additionally, attackers use automated and semi-automated CAPTCHA solvers, which are getting cheaper year over year.

Not all CAPTCHAs slow down the customer experience. Google has recently updated its reCAPTCHA verification tool to its third version. You don’t need to waste time and frustration solving a puzzle to prove you are a real human each time. The new mechanism allows you to weed out harmful traffic generated by bots silently and transparently. “reCAPTCHA v3 returns a score for each request without user friction,” Google said of the update on its developer page. “The score is based on interactions with your site and enables you to take appropriate action for your site.”

I recommend using the following strategies:

Consider a third-party authentication provider, such as Okta, and Web Application Firewall solutions, such as WAF from Imperva. Both have a range of security measures and constantly improve them.

Storing Passwords {#StoringPasswords}

Of course, there is no need to explain that passwords must be stored encrypted.

There are only four password hashing algorithms that are currently trusted by professional cryptographers and security researchers to protect users’ passwords: Argon2, winner of the Password Hashing Competition; bcrypt; scrypt; and PBKDF2, Password-Based Key Derivation Function #2. OWASP recommends the use of Argon2 as your first choice for new applications. If this is not available, PBKDF2 or scrypt should be used instead. Finally, if none of the above are available, use bcrypt. Among these, SAP Commerce Cloud supports PBKDF2, and this is the default strategy. All others are not supported out of the box but can be added easily if needed.

However, hashes by themselves are also insecure. For example, for the same passwords you will have identical hashes. To address this issue, the system can use a salted hash where a salt, a string appended to the password prior to hashing, is different or random per user. SAP Commerce uses the SHA1PRNG algorithm for generating a salt for passwords.

Third-party Identity Providers and Identity Federation {#3rdidp}

Identity Federation is a way for users to sign in using an account hosted on a third-party website, which is called an identity provider. You can delegate the security challenges to the identity provider, and you can receive profile information from it.

There are a number of services offering authentication services via APIs. This option works great if a large number of your customers have an account in such services, especially if they have already logged in there. It’s believed that the vast majority of typical internet users have an account in at least one of the three services: Facebook, Google, and Twitter.

For example, the authentication flow for Facebook based on OAuth2 works as follows:

However, if you use more than one provider, or you plan to use password-based authentication with third-party identity providers, we have a problem: how to merge different authentications if there is no single key. The data the social networks provide is provider-specific, and almost everything is optional.

Your app may need to handle more complex situations, such as:

It is possible that the customer used a different email to create their existing account than the one they have associated with their auth provider or social account or accounts. In this case, you should offer an “Account merging” option in the My Account area and allow the customer to manually specify the accounts that they wish to merge.

The system should also have the ability to unlink a third-party identity provider or social account or accounts from their normal in-store login account. The external account should be automatically unlinked from the login account when it gets associated with a new login account.

Third-party identity providers and social networks don’t always share the most merge-friendly data with apps. For example, Twitter doesn’t share the user’s email. Even if the email is technically provided, there is a case where users use different emails for different accounts. They can also decide to remove or hide the email associated with the account, as in Facebook or LinkedIn. Each provider limits access to user data from the application side. This is presented in the form of scopes, such as profile data, email addresses, age ranges, etc. In other words, the defined scope gives the application access to a specific set of data.

For this problem, there are three solutions:

So the truth is that it’s impossible to effectively merge social account data. Often, customer service is not capable of linking or merging the accounts either because there is no simple way to validate over the phone if a caller and the social account holder are the same person.

The last option cannot be implemented reliably. The profile data provided by the social network does not always have a reliable key for merging. The email address is not shared by some social networks, and all other information can be faked easily.

So the best option is to let customers link their social accounts to the profile.

Many websites require you to link the accounts after you sign in using the third-party identity provider. For example, if you log in using Google Account, the system will ask you to log in with the native Best Buy account to link them together.

Social logins are not supported by SAP Commerce Cloud out of the box, nor are third-party authentication provider integrations.

List of OAuth providers:

Browser APIs for authentication {#browserapi}

There are a number of initiatives to standardize an interface for authenticating users to web-based applications and services using public-key cryptography. The new approach is not only to bypass the need for passwords but also to keep login data local to protect it from server hacks or interception.

The most interesting topic in this area is WebAuthn, Web Authentication, a new web standard published by the W3C. The technology is already supported in developer preview versions of Safari, as well as Chrome, Firefox, and Edge. Android and Windows 10 have the technology built in.

This cutting-edge topic deserves a separate article to review. Currently, we are experimenting with it and will share the details soon. Stay tuned!