This resource has been deprecated; please visit userfront.com/changelog instead.
Additions and updates to the Userfront platform
Added the GET /self endpoint to allow a logged-in user to read detailed information about themself. See Read own user data.
{
"mode": "live",
"userId": 5,
"tenantId": "demo1234",
"email": "[email protected]",
"name": "Jane Doe",
"locked": false,
"isConfirmed": true,
"isMfaRequired": false,
"data": {
"custom": "data"
},
...,
"tenant": {
"tenantId": "demo1234",
"name": "Demo Account"
},
"authentication": {
"firstFactors": [
{ "strategy": "password", "channel": "email" },
{ "strategy": "link", "channel": "email" }
],
"secondFactors": [{ "strategy": "totp", "channel": "authenticator" }]
},
"authorization": {
"demo1234": {
"roles": []
}
}
}It is now possible to use your account-level API key or JWT access token to manage roles for your nested tenants.
This means you can have a structure like the following:
- Your account
- Organization A
- Workspace A1
- Workspace A2
- Organization B
- Workspace B1
- Workspace B2
- Organization A
Each level can have its own roles, and each user can have roles at any level, or at multiple levels. For example, a user could be a viewer at the account level, an editor in Organization A, an owner in Workspace A2, and a guest in Workspace B1.
You can manage roles for each user using the Roles API endpoints.
The new Userfront dashboard is live, with many new features.
-
New dashboard home page that includes insights and top users for your account, automatically calculated based on your application's activity.
-
Insights page with additional insights.
-
Security report with detailed information about all of your security settings, all in one place.
-
MFA configuration page that allows you to configure which factors you want to use for MFA, and whether it should be required for all users.
The old dashboard will remain available at https://old.userfront.com through the end of 2022.
Now you can nest tenants an additional level, allowing you to create sub-organizations within your application.
- Your application
- Organization A
- Workspace A1
- Workspace A2
- Organization B
- Workspace B1
- Workspace B2
- Organization A
See the create child tenant endpoint to create a nested tenant. Once you have created a child tenant, the other existing endpoints work the same as for the parent tenant.
Userfront now records all signup and login activities to help identify usage patterns and attempted unauthorized actions. These events and metrics will soon be available to view in the dashboard.
Userfront now aggregates user activity into daily and monthly summaries for your account. This includes:
- Daily Active Users (DAU)
- Daily new users
- Monthly Active Users (MAU)
- Total users
- Top existing users
- Top new users
- Calendar heat maps for signups
- Calendar heat maps for activity
- Cohort analysis
This aggregate information will soon be available to view in the dashboard.
All nonce-based security methods now have enhanced security, with brute-force detection and blocking built in.
By default, each link can only be guessed 10 times before the link credentials will be marked as invalid. Userfront also records these attempts, and in the future will notify you when they occur.
This change adds additional brute force security and monitoring to the following:
- Passwordless links
- Password reset links
- Verification codes
- SSO final step (Google, Facebook, Azure, Apple, etc.)
- SAML exchange
- MFA first factor token
For user CRUD operations, Userfront now returns a list of authentication methods that are valid for the user:
{
"authentication": {
"firstFactors": [
{ "strategy": "password", "channel": "email" },
{ "strategy": "google", "channel": "email" }
],
"secondFactors": [{ "strategy": "totp", "channel": "authenticator" }]
}
}It's now possible to login with 2 more approaches:
- Login or signup via a single-use verification code sent either by email or SMS
- Login with a TOTP app such as Google Authenticator or Authy
Accompanying the verification code approaches above, the signup() and login() methods for Core JS now support the verificationCode method.
Accompanying the TOTP authenticator code approach above, the login() method for Core JS now supports the totp method.
Added the sendVerificationCode() method to Core JS. This method allows a user to request an email or SMS with a single-use verification code. The verification code can be used with login({ method: "verificationCode" }) mentioned above.
Added the updatePassword() method to Core JS. This method supersedes the resetPassword() method, which is now an alias, and allows for updating a user's password with their reset link credentials or while the user is logged in.
Single Sign-On is now available for Apple on both web and mobile. For mobile applications it satisfies Apple's requirement to include Apple as an SSO option whenever any other providers are included.
Users can now sign in via Oauth 2.0 using Azure with single tenant. Previously, this was only possible for multi-tenant Azure instances.
Added an API endpoint for Update own password that allows a user to update their own password when logged in. If the user does not have a password yet (e.g. if they signed in with SSO), this endpoint creates their password.
Added an API endpoint for Search tenants that allows searching for tenants by name, custom data attributes, and/or tenantId.
Added an API endpoint for Verify a phone number that allows a user to send a 6-digit verification code by SMS to the given phone number and then enter that 6-digit verification code to verify the phone number. Once a phone number is verified, it can be used for login or multi-factor authentication.
Added the ability to log in by receiving a 6-digit verification code by email. Users can receive their code and submit it to the verification code login endpoint to log in.
Multi-factor authentication (MFA) via TOTP (Time-based One-Time Password) / authenticator app is now available in alpha. This allows for MFA flows that use Google Authenticator, Authy, and other TOTP code-generating applications.
This feature is in closed alpha and will be in beta shortly, followed by general release.
As with SMS MFA, we will release SDK methods and integrate MFA into the toolkit in the coming weeks.
You can now disable all emails from Userfront, ensuring that there are no triggers that will generate an automated email from Userfront to your users. This feature will be added to the dashboard soon, and in the meantime you can contact us to set up this feature.
Previously, when making client-to-server requests from a mobile application or backend server in live mode, the request could include the x-application-id header in place of the origin header (which the browser sends). Now the request can additionally include either the x-origin header or the x-application-id header.
The chosen header should correspond to a live mode domain in order for the request to be considered live mode. For example:
{
"headers": {
"x-origin": "https://livedomain.com"
}
}The default behavior on Userfront is that when a user attempts to log in with a password but does not yet have a password set, Userfront sends the user a password reset email. This can happen with users who have previously signed in with SSO, for example.
With the the included noResetEmail: true flag, Userfront does not send the user a password reset email if they do not already have a password, and instead returns an error message.
Multi-factor authentication (MFA) is officially live through the use of security codes sent by SMS.
We will release SDK methods and integrate MFA into the toolkit as well in the coming weeks.
Authenticator MFA is next.
We improved our internal rate limiting infrastructure to further prevent unwanted access attempts and to harden the service overall.
Browser storage for JWT access tokens is now customizable. See the MDN docs for more information about cookie attributes.
| Cookie attribute | Default | Options | Notes |
|---|---|---|---|
SameSite |
Lax |
Strict, Lax, None |
|
Path |
/ |
Any path (e.g. /custom) |
|
Set Domain? |
false |
false, true |
Setting Domain explicitly will allow subdomains to read cookies. |
These options will be available in the dashboard shortly. If you need to adjust them in the meantime, please contact us.
You can now disable new user registration and allow only the users you add manually to sign in. This feature will be added to the dashboard soon, but in the meantime you can contact us to set up this feature.
Multi-factor authentication (MFA) is in production for alpha testing, with security codes sent by SMS.
Added search options, fixed some minor display bugs, and improved the documentation for user search. Added examples of advanced filtering with various combinations of and and or search queries.
The Generate Link, Invite User and Invite User to a role endpoints all generate email links with a set expiration by default:
| options.type | Default duration |
|---|---|
| login | 1 hour |
| welcome | 3 days |
| verify | 3 days |
| reset | 1 hour |
Now you can also specify custom durations for each type of link, up to 1 week and down to 10 seconds, using the options.duration parameter.
{
options: {
duration: "5 minutes"
}
}
By default, invite emails contain a login link that will log the user in directly. However, this flow does not ask the user to set a password right away. Now it is possible to use a password reset link in place of a login link in the invite email by using the options.type parameter.
{
options: {
type: "reset"
}
}
Programmatically create, invalidate, and delete API keys: admin, readonly, and webhook key types are supported. Rotate keys as needed to secure your application.
Now in test mode you can use test, dev, and password when registering a user or changing their password. This allows for faster testing.
Previously, user registration by SSO would fire a user created webhook with the user unconfirmed, followed closely by a user updated webhook with the user confirmed. Now only the user created webhook is fired, with the user already confirmed.
Simplified the process for generating certificates for live domains, and removed a bug that affected some subdomains when "include subdomains" was checked.
3rd party login with SAML is stable and in limited-party testing in advance of a public release.
Adding Oauth 2.0 login with Twitter, which is based on the Twitter 2 API (in beta). We are waiting for Twitter to implement some features such as profile lookup before we can publish Oauth 2.0 compliant login via Twitter.
Adding "Sign in with Apple" functionality, which is loosely based on Oauth 2.0 standard. Awaiting some confirmation from Apple regarding their long-term timeline before finalizing this implementation for all platforms.
Whenever a user is locked or unlocked, the User Updated Webhook will be sent.
Use a server-to-server API endpoint to generate link credentials (uuid and token) for use in custom login, welcome, and account verification emails.
Works the same as standard signup, but with the the included noSignupEmail: true flag, Userfront does not send the new user an email. Combined with "Link generation without email" above, this allows you to create fully custom signup flows.
Filter users by the roles they have in a given tenant.
Updated code examples for client-to-server docs.
Added documentation for "passwordless" flows to give a clearer picture of all the options for signup and login.
Users can now present a valid JWT access token, existing password, and the new password to update their password directly from the client.
Updated the response format for newer link generation endpoints to better match other API endpoints.
Old format (deprecated):
{
Message: 'OK',
To: '[email protected]'
MessageID: '12ac72f3-355f-4266-8c7d-05d0acdab703',
SubmittedAt: 2021-09-12T17:21:48.046Z,
}
Updated format:
{
message: 'OK',
result: {
to: '[email protected]',
messageId: '12ac72f3-355f-4266-8c7d-05d0acdab703',
submittedAt: 2021-09-12T17:21:48.046Z
}
}
Allow search by users' custom data attributes via the user search endpoint.
Add system and endpoints for creating and using refresh tokens in httpOnly mode. These tokens cannot be read by client-side JavaScript and are thus not susceptible to XSS attacks. Usage of httpOnly tokens requires a custom domain.
Added the ability to generate custom JWT access token formats (e.g. compact, verbose, OIDC) by manuallys setting a value for the tenant. We will eventually add the ability to configure this directly from the dashboard.
Added an API endpoint and webhook to delete tenants programmatically.
Changed the key pair signing configuration from pkcs1 to pkcs8 as the former has compatibility issues with certain PHP libraries. All future keys will use the new format, and existing keys can be rotated to use the new format if needed.
Included example projects for setting up Userfront with Vue.js (custom forms) and Node.js authentication + access control.