Embedded login for web applications uses cross-origin authentication unless you configure a custom domain for your tenant. Cross-origin authentication uses third-party cookies to allow for secure authentication transactions across different origins.
Lock Installation
You can install Lock via several methods. Select any of the following installation sources that best suit your environment and application.Installation Sources
Install via npm:npm install auth0-lock
Install via bower:
bower install auth0-lock
Include via our CDN (Replace .x
and .y
with the latest minor and patch release numbers from the Lock Github repository:
Latest Minor Release:<script src="https://cdn.auth0.com/js/lock/11.x/lock.min.js"></script>
Latest Patch Release:
<script src="https://cdn.auth0.com/js/lock/11.x.y/lock.min.js"></script>
It is recommended that production applications use a specific patch version, or at the very least a specific minor version. Regardless of the method by which Lock is included, the recommendation is that the version should be locked down and only manually updated, to ensure that those updates do not adversely affect your implementation. Check the GitHub repository for a current list of releases.
Mobile
If you are targeting mobile audiences, Auth0 recommends that you add the following meta tag to your application’shead
:
<meta name="viewport" content="width=device-width, initial-scale=1"/>
Bundling Dependencies
If you are using browserify or webpack to build your project and bundle its dependencies, after installing theauth0-lock
module, you will need to bundle it with all its dependencies. Examples are available for Browserify and webpack.
Cross-Origin Authentication
Embedded login for web applications uses cross-origin authentication unless you configure a custom domain for your tenant. Cross-origin authentication uses third-party cookies to allow for secure authentication transactions across different origins.
Usage
Step 1. Initializing Lock
First, you’ll need to initialize a newAuth0Lock
object, and provide it with your Auth0 (the unique client ID for each Auth0 application, which you can get from the management dashboard) and your Auth0 domain (for example yourname.auth0.com
).
Step 2. Authenticating and Getting User Info
Next, listen using theon
method for the authenticated
event. When the event occurs, use the accessToken
which was received to call the getUserInfo
method and acquire the user’s profile information (as needed).
<h2>Welcome <span id="nick" class="nickname"></span></h2>
Note that if you are storing the user profile, you will want to JSON.stringify
the profile object and then, when using it later, JSON.parse
it, because it will need to be stored in localStorage
as a string rather than a JSON object.
Step 3. Showing Lock
Here you’re showing the Lock widget after the user clicks a login button; you can just as easily show Lock automatically when arriving at a page by just usinglock.show();
on page load.
This will show the Lock widget, and paired with the above, you’re now ready to handle logins!
Passwordless
Lock’s Mode is only available in Lock v11.2.0 and later. Please use the latest release of Lock for this feature! You can use Lock’s Passwordless Mode to allow users to authenticate using just an email or mobile number. They will receive the code and then return to input it, or click the link, and they can be authenticated without remembering a password. In Lock, in order to implement Passwordless Mode, you initialize Lock in a slightly different manner, withAuth0LockPasswordless
rather than with Auth0Lock
:
Passwordless options
Additionally, Lock’s Passwordless Mode has a couple of configuration options that are unique to it. In order to indicate which connection type you would like, you initialize Lock with theallowedConnections
option with either email
or sms
as the value:
email
, you have one more option to select - whether you wish your users to receive a code to input, or a “magic link” to use. This is done via the passwordlessMethod
option, which takes values of code
or link
.
Passwordless example
Single Sign-On with embedded authentication
Apps with embedded login must meet two criteria in order to have (SSO).- Both of the applications attempting SSO must be first-party applications. SSO with third-party applications will not work.
- They need to make use of custom domains and have both the applications which intend to have SSO as well as the Auth0 tenant on the same domain. Traditionally, Auth0 domains are in the format
foo.auth0.com
, but custom domains allow you to use the same domain for each of the applications in question as well as your Auth0 tenant, preventing the risk of CSRF attacks.
Error Codes and Descriptions
When Lock is used for embedded login, it employs the/co/authenticate
endpoint, which has the following errors.
The error description is human readable. It should not be parsed by any code and it subject to change at any time.
Status | Code | Description |
---|---|---|
400 | invalid_request | Invalid request body. All and only of client_id, credential_type, username, otp, realm are required. |
401 | unauthorized_client | Cross origin login not allowed. |
400 | unsupported_credential_type | Unknown credential type parameter. |
400 | invalid_request | Unknown realm non-existent-connection. |
403 | access_denied | Wrong email or password. |
403 | access_denied | Authentication error |
403 | blocked_user | Blocked user |
401 | password_leaked | This login attempt has been blocked because the password you’re using was previously disclosed through a data breach (not in this application). |
429 | too_many_attempts | Your account has been blocked after multiple consecutive login attempts. We’ve sent you a notification via your preferred contact method with instructions on how to unblock it. |
429 | too_many_attempts | We have detected suspicious login behavior and further attempts will be blocked. Please contact the administrator. |