Skip to main content
❰Release Notes

Authress Tenant selection enables your users to be automatically redirected to their own corporate identity provider during authentication.

Authress optimizes for the User Experience. To do this, Authress attempts to keep your users logged even when the token expires. This is known as Silent Authentication By default, Authress generated JWTs expiry after 24 hours, and session expiry after 30 days. This may not be long enough or too long in some circumstances.

To handle compliance and regulatory requirements. Authress now enables changing the default token and auth session expiries to meet your customers' exact needs. With this release, the Authress Tenant token configuration, can be provided to change one or both of these lifetimes. This configuration is available either through the SDKs and the Authress API or through the Authress Management Portal in the SSO Tenant Provider configuration.

When configuring an SSO Tenant in the Authress Management Portal, navigate to the advanced tenant configuration, and specify values for the Token Configuration:

Tenant token configuration

❰Release Notes

Authress Tenant selection enables your users to be automatically redirected to their own corporate identity provider during authentication. Some users will prefer public federated providers, such as Login with Google, but for those where SSO provides critical security, tenants are the preferred solution. Authress supports custom Tenant and Identity Provider selection based on either the Tenant ID or the Tenant Lookup Identifier. Often these might be a commonly available customer subdomain or a custom domain for your platform. In some cases, you might have customers with multiple email domains in the same organization or customer tenant. Common examples include when a customer has multiple business units and each business unit has their own email domain. Users from either business unit who should be part of the same tenant, should be automatically mapped based on any number of different email domains.

With this release Authress now supports multiple domains, by default up to 10 different eTLDs. This configuration is available either through the SDKs and the Authress API or through the Authress Management Portal in the SSO Tenant Provider configuration.

When configuring an SSO Tenant in the Authress Management Portal, now, the option to select the Tenant's email domains is now available:

Multiple email domains

This functionality will be activated when one of your users in one of your tenants attempts to log in with their email in the Authress Managed Login Screen. In this case, we can see company.com being entered, and the correct tenant will be selected based on that email:

Customizeable login box

❰Release Notes

Link user identities automatically when the user signs up for a more seamless user experience. Starting today, Authress provides a new configuration option allowing for the automatic linking of user identities. When a user signs up with a new account, if that account identity passes our first level security checks and matches an already existing user identity saved in Authress, then Authress can link these.

Identity Connection Configuration

Linking identities​

User identity linking supports the following three modes.

Disabled​

Do not link identities and do not allow users to link identities manually. This options should be used by default in Business Contexts, when user identities and data is owned by a business.

Explicit​

Allow users to link identities by utilizing the Link Identity API via loginClient.linkIdentity() call in the Authress Login SDK. More details about how to do this can be found under linking user identities in the Authress Knowledge Base.

Automatic​

Authress will attempt to automatically link user identities when available. Authress will utilize the email address of the identities as well as other key properties to decide if it is safe to link. In the case that it is Authress will automatically link the identity.

❰Release Notes

Authress automatically provides an audit trail of access to all your resources. Every authorization request and every user login is tracked and streamed to one of our cloud technology partners. For example AWS and GCP both have first class integrations, and you can review their respective guides.

There are many types of events, such as Login and User Authorized. These events are now available in the Authress Management Portal. The dashboard contains a list of the most recent requests to Authress and their result as well as aggregates for the types of requests, their responses, and your most frequently used resources:

Authress authorization metrics

❰Release Notes

Authress supports new configuration for security keys, multifactor authentication, and passkeys.

Until now, you've been accustomed with the Authress authentication login box.

Customized login box

MFA Hardware and software keys​

Authress now supports Hardware and software keys with any connection, users can add any number of additional keys to their account to be used as a second factor. These can be and should be used when any federated or social provider is enabled and your users don't want to trust solely a single provider for their identity. Additionally, in some regulated spaces, you might need a FIPS certified strategy for authentication.

User configured security keys:

Security Keys

Authress Security Keys​

Next, Authress also supports this same MFA strategy. To improve the security of your Authress account itself, you can add multiple MFA keys to your login, through the Security Keys profile option via the Authress Management Portal:

Authress Security Keys

Passwordless Passkey support​

Lastly, we've enabled Passkeys as a first factor as well. Now, those same security keys can be used to authenticate users without needing a username and password. Passkeys are the only truly safe passwordless authentication strategy.

Enable passkeys for your available login connections in one step on the Authress Identity Connections screen.

Enable passkeys support

❰Release Notes

Authress supports authentication and authorization among other first-class features. Where possible, it is better to accept these identity providers through Authress using an Identity Connection.

However, you may wish to continue using your existing authentication provider with Authress when switching to Authress authentication is not possible. In these cases, because most identity providers do not support granular authorization and permissions management, it is a common augment your existing authentication and identity provider (IdP) with Authress Authorization and access control.

This configuration in Authress is called OIDC External Trusted Identities, and starting today, these identities can be used to generate custom user IDs.

Until now, when using an external trusted identity, the User ID was required to be the sub claim of the provider's generated JWTs. Now it can be any claim found in the JWT and that resultant User ID can also have a custom prefix.

This helps disambiguate different providers that have overlapping User ID spaces, allowing you to better restrict access to a single unique user ID.

Check out the new User ID Expression attribute available both through the API and in the Authress Management Portal:

External Identity Provider configuration

This configuration would generate a User ID google|1000-google-user-id.

❰Release Notes

The default limit for the number of allowed groups and access records has been increased from 100,000 to 2 million. This change applies for both Groups and Access Records.

Before this change, searching for Access Records or Groups using the search query dialogs in the Authress Management portal, might not have returned exactly the correct results. However, starting today, a high usage of access records or groups when searching will now be a much better experience. It's important to clarify, more complex queries will always take more time to complete.

If you're interested in using this improved functionality via one of our SDKs as well, we would love to hear about it.

We still plan to roll out additional improvements in the near future, so stay tuned. As always, if you run into any issues with the portal, please reach out to our development team via our Support Page so we can get those issues resolved.

❰Release Notes

Through our ongoing efforts to make the Authress Management Portal easier to use, nicer to use, prettier to use. We've introduced the following improvements.

User Explorer Icons​

Until now, when one of your users had a picture claim associated with their user identity, it would not show in the portal. Now all safe user icons will be automatically displayed.

User Explorer Icons

Profile pictures will be displayed if the images for the user are sourced from one of the following locations:

  • Google
  • Secure Gravatar
  • Slack Avatars
  • Authress identity pictures

There are more coming to this list. However, not all pictures will be automatically shown. This is because not all image hosting locations are secure, and if a malicious image is uploaded to that location, and isn't validated, showing it to you in the management portal creates an attack surface. For this reason, be careful of media platforms that allow users images to be shown to you without taking the necessary security precautions. If there is a source location you would like added to this list and we can verify that provider is taking the necessarily precautions with shared images, it will be added.

Access Record Resource Hints​

Access Records resources dropdown will now dynamically populated with suggested resources. This makes it easier to filter and find the resource URI that are looking for. It also helps to avoid potentially guessing when the resource isn't present.

Access Record Resource Hints

Resource Tags​

Just as environment were displayed before, now all Authress related resource tags will be visible in the portal as well.

Resource Tags

❰Release Notes

The Authress Access Analyzer is our way of giving you the advanced tools you need to answer the complex authorization question you might have.

Questions such as:

  • Does that user really have the correct permission to the resource?
  • What's that user's access right now?
  • What are all the resources the user has access to with this permission?

While these actions are at the forefront of Authress authorization checks and done usually via one of the Authress SDKs, getting answers to these questions directly in the Authress Management Portal, makes it so much easier.

This release includes two new features for the Access Analyzer.

Access Record Source​

When a user has access to a resource via an access record, the Access Analyzer now shows that linked access access record as well as the role that granted the access.

Linked Access Record information

Access Check History​

After each access check the Authress UI will now save and display these checks to make it easier to see what was just validated. This makes it possible to compare a list of authorization checks for anything that might not be working correctly.

Authorization check history

❰Release Notes

The Authress API endpoint for querying users /v1/users now accepts filtering by a tenantId. This enables custom user workflows based on your customer's accounts.

Your customers accounts can be grouped by an identifier known as a Tenant. A Tenant is a logical source of users for your application. Usually Tenants map one-to-one with your customers. Each of your customer accounts has users that log into your application. During the use of your application there may be a need to fetch all the users that also belong to that same customer account.

This can now be done by passing in the tenantId query parameter to the List Users endpoint.

Authress has automated away the Login configuration experience. Instead of having to built your own login screen, Authress supports a managed version for you to configure.

List Users API endpoint

❰Release Notes

Authress introduces Vanishing Keys. Vanishing Keys is an open source one time secret store to enable ease of secret transfer.

In most cases, secrets should be generated and stored by the creator of the secret. And where possible secrets should only be generated at runtime. For this solutions such as a Key Management Service exists.

However, this is not always possible, and we need to transfer ownership of a secret from one person to another.

More details about how the Vanishing Keys service works is available in the documentation, but the important part of this new Authress service is that it provides 100% client side encryption. The secret and secret passphrase never leave your browser unencrypted.

Creating a Secret​

Authress Vanishing Keys

Authress Vanishing Keys

How it works​

Authress Vanishing Keys

❰Release Notes

To enable increased security and reliability Authress offers the ability to set a Custom Domain for your account. A Custom Domain enables your services to interact with Authress on a domain that you control. Any domain you own can be set. That domain will be used for:

  • API calls to Authress from the SDKs you configure
  • JWTs Authentication that Authress generates for your services

Historically, only one domain could be configured per account. In most cases you will only want a single domain, since it can create complex additional scenarios to deal with. For example, if valid tokens created by Authress now can be signed with either of two possible domains, now your services need to deal with two possible JWT Issuers.

In some cases this is intentional though, or perhaps you are in the process of rebranding, and need more than one domain to be active at the same time. Because of that, Authress now offers support for multiple simultaneous domains.

Enable an Authress custom domain

❰Release Notes

Starting today multiple wildcard support is globally available. Requests to check authorization can include multiple ✶ anywhere in the resourceUri. Requests to the authorization check endpoint accept resourceUris for example:

  • In multiple places in the hierarchy: /resources/✶/nested-resource/✶
  • Present in requests for namespaces: namespace:✶/resources/lower-namespace:✶/nested-resource

API update: Resource List​

To further support this functionality the List user resources endpoint now accepts a new parameter Collection Configuration that explicitly enables the type of collection result a request expects.

The original functionality was to only return immediate top level resource matches to a request. This functionality remains the default. When searching for /resources/✶, the result will be a list of matching resources: [ 'resources/001', 'resources/002', ... ].

The endpoint now supports INCLUDE_NESTED.

API Resource List

Specifying this value cases deeply nested resources to also be returned. A request for /resources/✶, will return: [ 'resources/001', 'resources/002/sub-resource/✶', 'resources/003/sub-resource/003' ]. And additionally requests can include multiple wildcards: /resources/✶/sub-resources/✶, will filter by both resources and sub-resources.

info

What's great about this new functionality is that users with access to ✶ will also successfully return results. Having access to all resources templates the result. ✶, with a search for /resources/✶ will return [ '/resources/✶' ], making it easier to utilize these results without adding extra filtering logic.

❰Release Notes

Authress has automated away the Login configuration experience. Instead of having to built your own login screen, Authress supports a managed version for you to configure.

Customized login box

The customized login screen is dynamically generated from account configuration. And allows further customization based on:

Standard Apps​

This is purely add-on functionality. Login for regular apps will continue the same as it has been, and your users will not see any difference. You can continue to directly overwrite the default Authress Login Box by passing the connectionId to loginClient.authenticate() call in the Authress Login SDK.

Platform Extensions​

For platform extensions, the default login experience has just been upgraded. If you didn't already have a customized login screen for third party extensions, the Authress managed version will automatically be provided without any additional configuration necessary on your side.

❰Release Notes

Authress now supports automated resource creation and configuration via Terraform.

Terraform provider for Authress

CI/CD Guides​

To support a more streamlined integration, Authress offers guides for Terraform as well as OIDC CI/CD guides for GitHub and GitLab. These CI/CD guides make managing Authress resources securely a simple matter without needing to be a security expert.

Quick setup guide for OIDC​

Additionally, Authress has released a quick setup guide for OIDC. The guide steps through the flow to secure a CI/CD pipeline automatically without needing to create an Authress service client. Instead, Authress supports the dynamic credentials that are generated by your CI/CD platform to log into Authress. Follow the relevant OIDC CI/CD for more details.

❰Release Notes

Starting today, the statements in an access record, can now additionally specify both users and groups.

User based access records​

Historically, users and groups were only available as properties of the access record, which meant all statements applied to all users and all groups. This made it easy to support having one group of users with many statements. Additionally, access records could be directly associated with a user so that it was clear that changes to an access meant changes for that particular user.

To change a user's permissions, it was as simple as looking up the access record with the same ID as the user:

Fetch an Authress access record
const record = await authressClient.records.getRecord(userId);

And then making necessary changes to that record.

Resource based access records​

However, when multiple users each needed different access to the same resource, multiple access records would need to be configured. One for each set of permissions. This was because all statements in the access record applied to all users in the record. To have different permissions, separate records would be created, each with the separate set of users.

Now, access records can directly specify which statements should be applied to which users.

Instead of listing the users at the record level:

Access record users

Toggle the Enable statement level user assignment switch:

Enable statement level user assignment switch

And then enter the users in the statement section of the record. Each statement can have separate users:

Access record statement user selection

❰Release Notes

A new menu item is available in Authress to quickly create new commonly used flows. These flows are knows as Quick Setup Guides and will be populated frequently used options.

Authress quick setup menu item

See the Quick setup guides.

Quick setup guide for authentication​

The first released setup guide is for authentication. The guide steps through the flow to create an application, a connection to an OAuth identity provider, and provides example UI code to directly log a user in.

On the completion of the flow you can already start managing user identities.