> ## Documentation Index > Fetch the complete documentation index at: https://docs.m1amdocs.com/llms.txt > Use this file to discover all available pages before exploring further. # Authenticate User Process This Process enables a user to sign into your client (or more specifically, into Storefront Gateway). This is a straightforward operation with additional options for additional user verification (e.g., multi-factor authentication, reCAPTCHA). **Note:** This Process operates differently from most other Processes, in that: * It is not started by the standard [Process Start](c_processStart) API, but its own dedicated endpoint, the [Session Start](c_sessionStart) API * It needs a required payload (authN ID and password) in the initial request body ## Process Flow This section describes the Authenticate User from a high-level, "happy path" flow. **Preconditions** * The user has a registered and activated User ID (i.e., Storefront Gateway User entity) and authN ID (i.e., email or mobile). * The user is currently anonymous (i.e., they are not authenticated in Storefront Gateway). **Basic Flow** 1. The user navigates to the client application's login portal, enters their authN ID and password, and then clicks **Sign In**. 2. (**Conditional - reCAPTCHA**) If the client has integrated Google's reCAPTCHA service, then Google silently checks whether or not the user needs to provide who they are. If so, Google returns a validation token to the client when the user passes that check. The client passes that token along to Storefront Gateway with the user's authN ID and password. Storefront Gateway verifies the token on a separate call to Google. * See the [Authentication with reCAPTCHA](c_useCaseRecaptcha) use case for more details. 3. Storefront Gateway consumes and validates the user's credentials, and checks the User's current status. * All Users (or User Profiles, User IDs, etc) are stored in the cloud as Storefront Gateway User data entities. * A user's authN IDs are registered and stored as attributes on the corresponding Storefront Gateway User entity. * A User entity and its authN IDs each have a **`status`**. The Process checks these statuses during sign-on. * If the authN ID has an **`activating`** status, then the user hasn't verified their email/mobile. * If the authN ID has a **`pending`** status, the user is replacing an email/mobile, but haven't verified the new one. * If the user attempts to login with an unverified email/mobile, the Process simply issues and sends an [action token](c_actionTokens) to that external channel for verification, and then ends without authenticating the user. * Storefront Gateway **does** allow users to register a non-verifiable authN IDs as a unique "alias," and the Authenticate User Process does accept aliases for sign-in. However, the user must have at least one verified email/mobile before they can register and use an alias. 4. (**Conditional - MFA**) If the user has one or more MFA options registered, and they are signing in from a device that is not currently "trusted" by the service, then Storefront Gateway sends a verification code to the end user's registered MFA channel (either an email, mobile number, or authenticator app). The client prompts the user is prompted to provide that code, and the user does so. * See the [Authentication with MFA](c_useCaseMFA) use case for more details. 5. If the user has passed any additional security protocols, and their credentials are all valid, then Storefront Gateway opens a user session on the server. **Post-conditions** * The user is now authenticated in Storefront Gateway. * The client may want to run the `GET /user` and any other entity management APIs to load the relevant user profile or otherwise "authenticated view" of the application. **Possible or Common Errors** * The Storefront Gateway User is currently locked after reaching the maximum number of failed authentication attempts. * Invalid or unknown authN ID. User not found in the Storefront Gateway data store. * The Storefront Gateway User (and/or the authN ID) is not yet verified. **Authentication with Social Media** Storefront Gateway also supports the option for a user to authenticate using a social media account that is associated to their Storefront Gateway User ID. See the Social Onboarding Use Case of the Onboard and Authenticate User with Social Account Process for more information. ## App Settings Certain aspects of the Process' behaviour are controlled by configurable system settings. Your organization can manage these and other settings in the Storefront Gateway Admin console. | Application Settings | Default Setting | | | - | - | - | | **Max failed sign-in attempts** | The maximum number of times the Process accepts bad input before locking the user out. | 10 failed attempts | | **Count failed attempts within** | The length of time in which the user's total failed attempts are counted towards lockout, measured in seconds. After this time expires, the count resets. | 3600 seconds | | **User lockout duration** | The length of time that a user ID lockout lasts, measured in sections. | 3600 seconds | | **Enable reCAPTCHA** | Enables Invisible reCAPTCHA, [version2](https://developers.google.com/recaptcha/docs/invisible). Enabling reCAPTCHA also includes setting additional fields for client and test secret keys. | Enabled | | **tokenURL** | Base for the action token URL to include in the notification message sent to the user's external channel. The actual token value will be appended to this String to form the complete URL. This app setting is applicable for when a user attempts to sign-in with an unverified email/mobile. When this occurs, the Process (re)sends an action token out to that email/mobile for verification. | [https://idp/user\\\_confirm?token\\\_value=](https://idp/user\\_confirm?token\\_value=) | | **Token (long-form) Expiration** | Determines the number of minutes before a verification link expires. | 10080 minutes (7 days) | | **Token (short-form) Expiration** | Determines the number of minutes before an OTP expires. **This setting is not configurable; it is noted here for context**. | 5 minutes | | Your organization can manage settings in the Storefront Gateway Admin console. | | | ## User Journey Flow Diagram This diagram illustrates the standard user journey with the Authenticate User Process, and some of the paths the Process can take based on settings and/or user input. This diagram also incorporates potential paths with reCAPTCHA, MFA, and the **Activate User** Process. ## Use Cases The following links provide guided walkthroughs of the Authenticate User Process: * [Standard user authentication](c_useCaseAuthentication) (authN ID + password) * [Authentication with reCAPTCHA](c_useCaseRecaptcha) * [Authentication with MFA](c_useCaseMFA) * [Authentication errors](c_authnErrors) ## See Also * If the user attempts to sign in with a registered but unverified email address or mobile number, then the Process will (re)send an action token to that channel for verification. This is functionally similar to (but distinct from) the [Send Verification](c_sendVerification) Process. * [The Onboard and Authenticate with Social Account](c_onboardAuthenticateUserSocial) Process facilitates an alternative, passwordless authentication method for users. * This Process supports clients integrating with Invisible reCAPTCHA. See [Google's own reCAPTCHA documentation](https://developers.google.com/recaptcha/docs/invisible) for more information on how to build reCAPTCHA into your application. * **[Standard User Authentication](c_useCaseAuthentication)** * **[User authentication with reCAPTCHA](c_useCaseRecaptcha)** * **[User Authentication with MFA](c_useCaseMFA)** * **[Authentication Errors](c_authnErrors)** **Parent topic:**[Identity Management Processes](../images/c_identityProcesses) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.