LoginRocket is our hosted logins and signups feature. Additionally, authrocket.js also relies on the LoginRocket API. As such, this page covers configuration for both.
Determines whether login-related functionality is enabled for LoginRocket and authrocket.js. This does not affect using the API directly from your app.
AuthRocket supports two SSO modes: Basic and Seamless.
Basic SSO allows multiple apps to all share the same set of users, but each app requires its own authentication. That is, if a user logs in to app A and then goes to app B, they’ll be required to login a second time.
Seamless SSO causes LoginRocket to remember the current login session after the first login. Not only can multiple apps share the same set of users, but now they can share login sessions and only have to authenticate once across all apps. In this instance, if a user logs in to app A and then goes to app B, LoginRocket will remember that the user is already logged in and will automatically log them into app B without making them authenticate a second time.
Seamless SSO requires managed sessions.
Determines whether signup-related functionality is enabled for LoginRocket and authrocket.js. This does not affect using the API directly from your app.
When a new user signs up (whether using a password, or a first-time user via social auth), there are several options of how to proceed.
Create Users will create a User record and then automatically log the user in.
Create Users+Orgs+Memberships will create a User record, an Org record, and a Membership record to connect the two. The Org will be named according to Organization name.
Create Signup Tokens will only create a Signup Token. Signup tokens are temporary holding containers that can later be used to create a User, or simply discarded. This option is particularly powerful as part of a more complex signup flow where other fields need to be collected and validated before the actual User is created.
For example, a user might signup for a SaaS app and then need to enter payment information. By creating a Signup Token, then signup can start with name & email (which is pretty natural), but then continue onto payment, all without the User being created yet. If payment fails or is never completed, the Signup Token is simply discarded. Assuming payment succeeds, then the Signup Token can be converted into a proper User record and the signup completed.
This is particularly powerful with authrocket.js because then signup and payment (or whatever else) can all be included on a single form. If the user resubmits the form several times, creating several Signup Tokens, this is no problem. Only the one that’s actually converted to a User will count.
These are the default permissions to add to the Membership when Signup mode is Create Users+Orgs+Memberships.
Determines whether email-verification-related functionality is enabled for LoginRocket and authrocket.js. This does not affect using the API directly from your app.
Disabling this does not stop verifications from being initiated (Verify emails for new users) but only prevents LoginRocket from being able to process the verifications. In this instance, you would process the verifications via your own app instead.
Newly created users (via LoginRocket or authrocket.js only) can be set to initiate the email verification flow automatically. If creating Users via the API, see User.email_verification instead.
No - Disables automatic verification. Verification can still be initiated via the API or management portal.
Request, but allow logins - Initiates verification while still allowing the user to login while the email remains unverified.
Require, and intercept logins - Initiates verification and intercepts logins (via LoginRocket and authrocket.js only) for unverified users, redirecting them to the verification page. Once verified, the logins will then complete. With this setting, only users who have a pending verification request will be intercepted. Users who are unverified but also have no pending request (eg: legacy users prior to this setting be enabled) will continue to be able to login.
For new signups, whether the First name and Last name fields be required, optional (ask), or not even shown (hide). Does not apply to new users via social login.
For new signups and password resets, whether to show just Password (just once) or show both Password and Password Again (with confirmation).
For new signups using Create Users+Orgs+Membershps mode, this is whether to collect a separate Organization name. When Required, will always prompt (even for social login). When Ask, will prompt for password-based signups, but if left blank (or if a social login), defaults to the user’s name. If Hide, always uses the user’s name.
Questions? Find a Typo? Get in touch.