Zum Inhalt springen

Auth0 Release Notes

613 Einträge aus 1 Quelle. Zuletzt aktualisiert:

Folge Auth0, um die Release Notes in deinen Feed zu holen.

Angaben zum Datum

Datum aus der Quelle.

Erstmals gesehen am .

Auth0

IP Allow List jetzt maschinenlesbar

Die IP Allow List für Auth0 Public Cloud Regions steht unter https://cdn.auth0.com/ip-ranges.json in einem standardisierten maschinenlesbaren Format bereit, sodass sich Firewall-Updates automatisieren lassen.

We are excited to announce an improvement that makes it faster and easier for you to keep your firewall configurations up-to-date. Our __IP allow list for Auth0's Public Cloud regions__ is now available in a standardized, machine-readable format. This new format is designed to help you automate updates and ensure the most accurate configuration for your firewall. What this means for you: - __Automation__: You can now programmatically fetch and parse the list, eliminating the need for manual updates. - __Accuracy__: The structured data ensures you're always using the latest and most accurate IP addresses. - __Clarity__: The changelogs highlight specific additions and removals, so you can easily see what has been updated. You can access this information at: [https://cdn.auth0.com/ip-ranges.json\](https://cdn.auth0.com/ip-ranges.json) For more details, please see our documentation on [IP allow list](https://auth0.com/docs/secure/security-guidance/data-security/allowlist).

Originalquelle(öffnet in neuem Tab)Problem melden

Angaben zum Datum

Datum aus der Quelle.

Erstmals gesehen am .

Auth0

Strengere Audience-Prüfung bei Private Key JWT

Auth0 akzeptiert im "aud"-Claim von Private-Key-JWT-Assertions künftig nur noch den Issuer-Identifier des Tenants als einzelnen String, die Angabe als Array oder als Endpunkt-URL ist veraltet.

When validating [JWT assertions used for client application authentication](https://auth0.com/docs/get-started/authentication-and-authorization-flow/authenticate-with-private-key-jwt), **Auth0 will impose stricter requirements and accept only a tenant's issuer identifier as a single JSON string value in the "aud" (audience) claim**. The possibility of providing an "aud" claim with either one of the approaches listed below is deprecated, and at a future date will cause the service to consider such JWT assertions invalid: * A JSON array of strings, provided that one of the entries contains a valid issuer identifier or endpoint URL for the respective tenant and endpoint the client authenticates against. * A single JSON string representing a valid endpoint URL for the respective tenant and endpoint the client authenticates against. OIDC enterprise connections configured to use Private Key JWT in authenticated requests to the upstream identity provider will also be able to use the applicable issuer identifier represented as a JSON string in the "aud" claim included in JWT assertions. We have provided additional information and timelines for enforcing this change across tenants through a dashboard and [support center notification](https://support.auth0.com/notifications/68e3e29a45f175778e64b020).

Originalquelle(öffnet in neuem Tab)Problem melden

Angaben zum Datum

Datum aus der Quelle.

Erstmals gesehen am .

Auth0

Akamai Supplemental Signals im Early Access

Enterprise-Kunden mit Akamai als Reverse Proxy können Signale von Akamai Bot Manager und Account Protector an Auth0 weiterleiten und in Post-Login Actions sowie Tenant-Logs nutzen.

We’re excited to announce the Early Access release of **Akamai Supplemental Signals**. This feature allows **Auth0 Enterprise customers who have Akamai configured as a reverse proxy** in front of Auth0 to forward signals from [**Akamai Bot Manager**](https://www.akamai.com/products/bot-manager) and [**Akamai Account Protector**](https://www.akamai.com/products/account-protector) into Auth0. With this integration, you can enrich your authentication flows with supplemental signals from Akamai and make more dynamic security decisions in post-login Actions and gain visibility through tenant logs. --- ### Key Benefits - **Combined Risk Context:** Leverage Akamai’s bot and user risk signals together with Auth0’s risk assessment for a more complete view of login risk. - **Adaptive Security Controls:** Combine Akamai and Auth0 risk signals to trigger MFA, deny sessions, or revoke access based on risk indicators. - **Seamless Integration:** Configure Akamai to forward signals and use them immediately in post-login Actions and tenant logs. --- ### Availability - Available to all **Enterprise customers using Akamai as a reverse proxy** in front of Auth0. - Currently in **Early Access**. --- ### Learn More - [Configure Akamai as a Reverse Proxy](https://auth0.com/docs/customize/custom-domains/self-managed-certificates) - [Configure Akamai to Send Supplemental Signals](https://auth0.com/docs/secure/attack-protection/configure-akamai-to-send-supp…

Originalquelle(öffnet in neuem Tab)Problem melden

Angaben zum Datum

Datum aus der Quelle.

Erstmals gesehen am .

Auth0

Zusätzliche Signaturalgorithmen für OIDC und Okta Connections

Im Limited Early Access unterstützen Okta und OIDC Enterprise Connections zusätzlich RS512, PS256 und ES256 für Private-Key-JWT-Authentifizierung und die ID-Token-Prüfung, der Zugang erfolgt über den Technical Account Manager.

We’re thrilled to introduce the __Limited Early Access__ release of __Additional Signing Algorithm for Okta and OIDC enterprise connections__! This release expands flexibility for both __Private Key JWT client authentication__ and __ID token verification__ by adding support for stronger signing algorithms beyond RS256, including: - RS512 - PS256 - ES256 For Private Key JWT, Auth0 now lets you choose which algorithm is used to sign client assertion JWTs when authenticating requests to an upstream IdP. For ID token verification, Auth0 can validate tokens signed with a wider set of algorithms, ensuring compatibility across OIDC flows. Together, these enhancements give customers more control over cryptographic choices, making it easier to align with security policies and adapt as standards evolve This release is currently rolling out to all environments. To enable the Additional Signing Algorithms Limited Early Access release in your Auth0 tenant once available in your environment, please contact your Technical Account Manager to request access.

Originalquelle(öffnet in neuem Tab)Problem melden

Angaben zum Datum

Datum aus der Quelle.

Erstmals gesehen am .

Auth0

Auth0 React Native SDK 5.0 (GA)

Das Auth0 React Native SDK v5 ist eine grundlegende Neuentwicklung mit Kompatibilität zu React 19 und Expo 53, Beta-Unterstützung für die New Architecture, einfacherer API, in Kotlin neu geschriebener Android-Schicht und Support für react-native-web.

We are excited to announce the release of the __Auth0 React Native SDK v5__, a foundational rewrite designed to provide a best-in-class developer experience for one of the world's most popular mobile frameworks. This major update delivers a simpler, more powerful way to integrate secure authentication into your React Native applications while ensuring compatibility with the latest evolution of the ecosystem. __Highlights:__ - __Stay on the Cutting Edge of React Native:__ Deploy with confidence knowing your authentication layer is ready for the future. The SDK is fully compatible with React 19 and Expo 53, and now includes Beta support for React Native's New Architecture (Turbo Modules). This allows you to leverage the latest performance and UI capabilities of the ecosystem without compromising on security. - __Accelerate Development with a Better DX:__ We've refactored the entire SDK from the ground up to create a more intuitive and efficient developer experience. With a simpler API surface, unified cross-platform error handling, and an Android layer rewritten in modern Kotlin, you can integrate Auth0 faster and spend less time debugging. - __Build for More Platforms with react-native-web:__ The new, robust architecture enables first-class support for react-native-web. Now you can share more of your authentication logic between your native mobile and web applications, streamlining development and ensuring a consistent user experience everywhere. Get Starte…

Originalquelle(öffnet in neuem Tab)Problem melden

Angaben zum Datum

Datum aus der Quelle.

Erstmals gesehen am .

Auth0

Ephemeral Sessions mit Actions (Public Early Access)

Enterprise-Tenants können per api.session.setCookieMode("non-persistent") in Post-Login Actions Sessions erzeugen, die nur im Speicher existieren und beim Schließen von Browser oder App gelöscht werden.

As part of the Continuous Session Protection, you can now configure ephemeral (non-persistent) sessions using Actions. This allows enterprise customers to dynamically control whether a session is stored in a persistent cookie or only in memory. Ephemeral sessions: - Exist only in memory and are cleared when the browser or app is closed - Are ideal for high-sensitivity workflows such as step-up authentication or use on public devices - Can be configured per session using `api.session.setCookieMode("non-persistent")` in post-login Actions This feature is available to all Enterprise tenants in Public Early Access and requires no enrolment. Learn more: https://auth0.com/docs/manage-users/sessions/sessions-with-actions#set-session-persistence-with-actions and https://auth0.com/docs/manage-users/sessions/session-lifecycle [Use Ephemeral Sessions with Actions to configure Keep Me Sign In](https://auth0.com/docs/manage-users/sessions/configure-keep-me-signed-in-sessions)

Originalquelle(öffnet in neuem Tab)Problem melden

Angaben zum Datum

Datum aus der Quelle.

Erstmals gesehen am .

Auth0

Organizations-Unterstützung für Native Passkeys

Native Passkey-Flows für Anmeldung und Registrierung können nun die Organisation übergeben und unterstützen die automatische Aufnahme in eine Organisation, derzeit im Limited EA.

You can now use __Organizations with your native passkey flows__! User sign-in and registration flows can now pass the organization to complete sign up in the organization context. Like Universal Login flows, auto-enrollment into an organization during sign-in is also supported. __Organizations Support for Native Passkeys__ is in Limited EA - reach out to your Auth0 contact to get started today. To get started with Passkey APIs and use them with Organizations, please see our [documentation](https://auth0.com/docs/native-passkeys-api) or read our [blog](https://auth0.com/blog/how-to-signup-and-login-with-passkeys-android/ "How to Sign Up and Log In with Passkeys in Android Using Auth0's Native Login") for getting started with native applications.

Originalquelle(öffnet in neuem Tab)Problem melden

Angaben zum Datum

Datum aus der Quelle.

Erstmals gesehen am .

Auth0

Native Passkey Management in MyAccount verfügbar

Über die MyAccount-API lassen sich Passkeys jetzt per API löschen und alle registrierten Authentifizierungsmethoden eines Nutzers auflisten, sodass die Passkey-Verwaltung in native Apps integriert werden kann (Limited EA).

We’re very excited to announce the availability of __Native Passkey Management__, extending the management of authentication methods using APIs. Customers can now delete passkeys using APIs and list all enrolled authentication methods for a user. Customers can build end-to-end management of the passkeys directly into their native applications. __Native Passkey Management__ is in Limited EA - reach out to your Auth0 contact to get started today. To get started with MyAccount please read our [documentation](https://auth0.com/docs/manage-users/my-account-api "MyAccount API")

Originalquelle(öffnet in neuem Tab)Problem melden

Angaben zum Datum

Datum aus der Quelle.

Erstmals gesehen am .

Auth0

Self-Service User Provisioning (SCIM) im Early Access

Kunden-IT-Teams können SCIM nun direkt im Self-Service-SSO-Assistenten einrichten, und neue User Attribute Profiles (UAP) vereinheitlichen die Zuordnung von Benutzerattributen über SAML, OIDC und SCIM hinweg.

We’re excited to share that we've expanded the Self-Service SSO experience with __User Provisioning (SCIM)__. Now your customers’ IT teams can manage user onboarding and offboarding directly, reducing manual work for you. This feature is currently in __Early Access__. __Smarter Provisioning__: Your customers can now configure __SCIM directly in the Self-Service SSO wizard__, streamlining setup and reducing time-to-value. __Unified User Data__: This release introduces __User Attribute Profiles (UAP)__, a standardized way to map, normalize, and sync user attributes across identity protocols (SAML, OIDC, SCIM) and Auth0’s Self-Service SSO feature. This ensures consistent data handling across integrations and simplifies ongoing maintenance. Furthermore, when using UAP with the Self-Service Profile and Self-Service SSO, those mappings are now used to populate the Enterprise Connection Mapping object in Auth0. __Key Benefits__ - __Automation__: Delegate SCIM setup to your customers’ admins - __Interoperability__: Works seamlessly across varied IdPs - __Consistency__: One schema for easier debugging and support - __Flexibility__: Override mappings per protocol when needed ![User Provisioning](//images.ctfassets.net/kbkgmx9upatd/1sLKLMX9mHZ3fwwnYVtM0p/bf92648b962e8ab7127231222020f59a/SS-SCIM.gif) Rollout is happening now. No opt-in required, it’s ready as soon as it appears in your tenant. Learn more about [Self-Service](https://auth0.c…

Originalquelle(öffnet in neuem Tab)Problem melden

Angaben zum Datum

Datum aus der Quelle.

Erstmals gesehen am .

Auth0

Cross App Access (XAA) für Resource Applications in Beta

Cross App Access (XAA) für Resource Applications ist in Beta und ermöglicht es SaaS-Anbietern, ihre APIs per Konfiguration im Auth0-Tenant ohne Codeänderungen für die sichere Anbindung von KI-Agenten und anderen Apps mit zentraler Richtliniendurchsetzung bereitzustellen.

We're excited to announce that __Cross App Access (XAA) for Resource Applications is now in Beta__. __Connecting AI Agents and Third Party Apps in an enterprise__ introduces two key challenges: poor IT visibility into data sharing and repetitive user consent flows. Cross App Access (XAA) solves this by __enabling IT teams to centralize control over these connections__, eliminating constant user consent prompts and providing better governance and visibility into data sharing. This new feature provides __built-in support for SaaS providers to get their APIs ready for secure connection by AI Agents and other SaaS Apps in enterprise environments__. No code changes needed, simply configure the feature in your Auth0 tenant to instantly support central policy enforcement and a seamless user experience. This Beta release is for testing purposes only. To learn more, read our [documentation](https://auth0.com/docs/xaa-resource-app). ![XAA-Resource-Apps-Beta](https://cdn.auth0.com/blog/XAA-Resource-Apps-Beta.png)

Originalquelle(öffnet in neuem Tab)Problem melden

Angaben zum Datum

Datum aus der Quelle.

Erstmals gesehen am .

Auth0

Überarbeitetes Auth0 Support Center

Das neu gestaltete Auth0 Support Center bietet eine KI-gestützte Suche mit zusammengefassten Antworten, eine Knowledge Base, einen Product Hub und einen Learning Hub.

A new and improved Auth0 Support Center is now live. The new Auth0 Support Center is re-designed to help you find answers faster and adopt features more confidently. Here’s what’s new: - Summarized solutions, fast: A single AI-powered search scans thousands of support resources, and learning content, and delivers a single answer tailored for you. - Unblock faster, stay ahead: The new [Knowledge Base](https://support.auth0.com/center/s/knowledge) provides real-world how-tos and fixes. [The Product Hub](https://support.auth0.com/center/s/product-hub) keeps you up to speed on what’s coming next. - Level up your skills: The [Auth0 Learning Hub](https://support.auth0.com/center/s/learning) offers self-paced, tailored learning paths and plans to help you build skills and feature mastery. Ready to try it out? Head to the [Auth0 Support Center](https://support.auth0.com/center/s/) and explore for yourself. A great place to begin: search for a product or feature you’re working on and see how the new search delivers fast, tailored answers. Want to learn more? Check out the [YouTube video](https://www.youtube.com/watch?v=gNl1gEGYAbk&feature=youtu.be) and [Knowledge Base article](https://support.auth0.com/center/s/article/Announcing-the-Enhanced-Auth0-Support-Center).

Originalquelle(öffnet in neuem Tab)Problem melden

Angaben zum Datum

Datum aus der Quelle.

Erstmals gesehen am .

Auth0

Auth0 Teams: Einladungen mit vorab zugewiesenem Tenant-Zugriff

Beim Einladen neuer Teammitglieder lassen sich nun optional Tenants und Rollen vorab auswählen, die nach Annahme der Einladung automatisch gelten, und die Annahme wird zusätzlich im Team-Aktivitätslog protokolliert (Early Access für Enterprise-Kunden).

We're excited ✨ to announce a significant enhancement to Auth0 Teams that simplifies and accelerates the onboarding process for your team members. This new feature, Pre-tenant Assign in Team Invitations reduces the steps required to get your team members productive faster. __The Challenge We Solved ⁉️__: Previously, inviting a new team member and granting them tenant access was a multi-step process: invite, acceptance, then manual tenant assignment. __What's New 🎉__: You can now combine these steps into a single action. When inviting a new team member, an optional step in the invitation modal allows you to pre-select the tenants and associated roles the invitee should automatically access upon accepting the invitation. __Key Benefits for Your Team ✅__: - One-Step Onboarding: Reduce administrative overhead by combining invitation and tenant access assignment into one efficient workflow. - Immediate Access: Invitees gain immediate access to pre-assigned tenants upon accepting the invitation, eliminating waiting periods. - Improved Audibility: Team Activity logs now record "Invitation accepted" events for better visibility along with tenant member event detail logs. This feature empowers Team Owners to onboard administrators and contributors effortlessly, ensuring they have the right access from day one. __Availability 🍾__: Available in Early Access to Enterprise Customers, with General Availability coming soon. "__Do not have Teams enabled as yet?__ Click…

Originalquelle(öffnet in neuem Tab)Problem melden

Angaben zum Datum

Datum aus der Quelle.

Erstmals gesehen am .

Auth0

Bulk User Import/Export im Management Dashboard

Bulk-Import und -Export von Nutzern sind jetzt direkt im Auth0 Management Dashboard verfügbar, auch für Mitglieder mit der Rolle Editor - Users, inklusive Upsert bestehender Nutzer und Beispielexport mit 10 Nutzern, während die Bulk Import/Export Extension im Oktober 2025 ausläuft.

We are excited to share that Bulk User Import / Export is now available for everyone directly in the Auth0 Management Dashboard! __What’s New:__ - Streamlined experience: submit import / export jobs directly in the Dashboard UI - no Extension management required - Expanded RBAC support: now available to tenant members with *Editor - Users* Role in addition to Admin - Bulk update existing users: upserting pre-existing users in a connection is now available for manual import jobs - Export as a sample: quickly validate export file structure and field naming by exporting a sample file of 10 users __Deprecation Notice__ The [Bulk Import / Export Extension](https://auth0.com/docs/manage-users/user-migration/user-import-export-extension) __will reach end of life in October 2025__. We recommend switching to the new Dashboard experience as soon as possible. For more information on the new Import/Export UI, please refer to [Bulk User Import / Export](https://auth0.com/docs/manage-users/user-migration/bulk-user-import-export) in the Auth0 docs.

Originalquelle(öffnet in neuem Tab)Problem melden

Angaben zum Datum

Datum aus der Quelle.

Erstmals gesehen am .

Auth0

Tenant Access Control List (ACL) allgemein verfügbar

Tenant ACL ist allgemein verfügbar und erlaubt es, Anfragen anhand von Signalen wie IP, Geolokation, User Agent oder ASN zuzulassen, zu blockieren oder umzuleiten, mit einer Liste für Enterprise-Kunden, bis zu 10 Listen mit dem Attack-Protection-Add-on und Dashboard-Unterstützung.

We’re excited to announce the General Availability of Tenant Access Control List (ACL), a security feature that helps you control who can access your tenant. With Tenant ACL, you can create custom lists to allow, block, or redirect requests based on predefined signals – strengthening security and optimizing performance. ### Key Benefits - Reduce Attack Surface: Block malicious traffic before it reaches your tenant - Enhance Security: Enforce access policies based on IPs, geolocation, user agents, ASN, and more - Optimize Performance: Redirect traffic to improve user experience ### What’s New in GA - Enterprise customers: Create one Tenant ACL list - Attack Protection add-on customers: Create up to 10 Tenant ACL lists - Dashboard support: View, enable, and disable ACL lists directly from the Auth0 Dashboard ### Learn More - [Tenant ACL Documentation](https://auth0.com/docs/secure/tenant-access-control-list) - [Network ACL Management API](https://auth0.com/docs/api/management/v2/network-acls/get-network-acls)

Originalquelle(öffnet in neuem Tab)Problem melden

Angaben zum Datum

Datum aus der Quelle.

Erstmals gesehen am .

Auth0

API Access Policies for Applications im Early Access

Mit API Access Policies for Applications steuern alle Auth0-Kunden deklarativ, welche Anwendungen für eine bestimmte API Access Tokens erhalten können, getrennt für Nutzer- und Machine-to-Machine-Flows (Early Access, produktiv unterstützt).

We're excited to announce that API Access Policies for Applications is now in __Early Access for all Auth0 customers and is fully supported for production use.__ This feature enables you to control how applications access your APIs registered in Auth0. You can configure separate application API access policies for user access and client (machine-to-machine) flows, giving you __declarative, granular and easy-to-reason control over which applications can obtain an access token for a specific API__. For instance, with the require_client_grant policy, you can ensure that only explicitly authorized applications can get tokens, even during user flows. This strengthens your security posture by preventing unauthorized applications from accessing sensitive API resources on behalf of a user. To learn more, __check out the [documentation](https://auth0.com/docs/get-started/apis/api-access-policies-for-applications).\_\_

Originalquelle(öffnet in neuem Tab)Problem melden

Angaben zum Datum

Datum aus der Quelle.

Erstmals gesehen am .

Auth0

Dry Run für die Auth0 Deploy CLI

Die Auth0 Deploy CLI bietet im Early Access das Flag --dry-run, das vor einem Import zeigt, welche Ressourcen erstellt, aktualisiert oder gelöscht würden.

One of the most requested features for the Auth0 Deploy CLI is here: __you can now preview your deployment changes before applying them.__ Say goodbye to deployment anxiety. With the new --dry-run flag, you can __get a detailed summary of exactly what resources will be created, updated, or deleted__ before you run an import. This brings the confidence of infrastructure-as-code practices like terraform plan to your Auth0 tenant management. __Get started by simply adding the --dry-run flag__ to your import command to see a safe preview of your changes. This will help you and your team: - __Deploy with Confidence:__ Eliminate uncertainty by verifying the exact impact of your changes. - __Prevent Unintended Changes:__ Catch potential issues and avoid accidental modifications to critical production resources. - __Improve Collaboration:__ Share the dry-run output with team members for review and approval before deployment. The Dry Run feature is now available in Early Access. Update to the latest version of the Deploy CLI to get started. [Learn More](https://github.com/auth0/auth0-deploy-cli/blob/beta/docs/using-dry-run.md) ![deploy cli dry run image](//images.ctfassets.net/kbkgmx9upatd/1yYRD5CIwi3CYBmaffCTuA/73164b700b556c810392cfa27a88f75e/444405682-17f94ba1-f5cc-4e89-beb3-277895544e72.png)

Originalquelle(öffnet in neuem Tab)Problem melden

Angaben zum Datum

Datum aus der Quelle.

Erstmals gesehen am .

Auth0

Non-Unique Emails im Open Early Access

Mehrere Benutzerkonten können sich in neuen Datenbankverbindungen dieselbe E-Mail-Adresse teilen, wobei Username oder Telefonnummer als primärer Identifikator konfiguriert werden muss und die Einstellung nach Aktivierung dauerhaft ist.

**What's new:**\ **Non-Unique Emails** is now in **Open Early Access** and rolling out to all environments. With this feature, multiple user accounts can share the same email address within a database connection. This enables support for real-world scenarios like: - Parent/child accounts using a shared inbox - Small businesses with a single location email - Users managing multiple roles under one email address **Key details:** - Rollout has **just begun** and will take **1--4 weeks** to reach every environment. - Available only for **new database connections**. - Email **cannot** be used as a primary identifier, customers must configure **username** or **phone number**. - Email communications will still be delivered to the shared email. - Once enabled, the non-unique email setting is **permanent**. **Status:** - This feature is **production-ready**. - **No opt-in required**, all customers will gain access once rollout reaches their environment. - **GA planned for Q4 2025.** **Getting started:**\ Customers can create a new database connection with Non-Unique Emails in the **Dashboard** or via the **Management API**. See full documentation here:\ [Non-Unique Emails Documentation](https://auth0.com/docs/authenticate/database-connections/non-unique-emails)

Originalquelle(öffnet in neuem Tab)Problem melden

Angaben zum Datum

Datum aus der Quelle.

Erstmals gesehen am .

Auth0

Auth0 Teams: Tenant-Mitgliederverwaltung und SSO-Erzwingung für Private Cloud (Beta)

Private-Cloud-Kunden erhalten in der Beta zentrale Tenant-Mitgliederverwaltung und SSO-Erzwingung über Enterprise-IdP-Verbindungen in Auth0 Teams, dazu Protokollierung der Vorgänge im Activity Log und Session Revocation.

We are excited to announce a major update for our Private Cloud customers, extending the powerful management and security capabilities of Auth0 Teams to your private cloud environments. This release introduces the Beta versions of Tenant Member Management and SSO Enforcement, closing the feature gap with our Public Cloud offering. ## ✨ New Features __Tenant Member Management (Beta) for Private Cloud__: You can now centrally manage tenant membership and roles for your team members directly from the Auth0 Teams dashboard. This feature simplifies user administration by allowing you to: - View and manage all tenant access from a single interface. - Efficiently onboard and off-board users across multiple tenants. - Perform bulk operations to grant or revoke access. __SSO Enforcement (Beta) for Private Cloud__: Strengthen your organization's security posture by requiring all team and tenant members to authenticate using one of your configured Enterprise Identity Provider (IdP) connections. This ensures that access to Auth0 resources is governed by your corporate identity solution. __Activity Log Integration for Tenant Management__: All operations related to Tenant Member Management (e.g., adding, updating or deleting) are now recorded in the Auth0 Teams Activity Log, providing a complete audit trail for compliance and security monitoring. (**Note** Now available to all Auth0 Teams customers.) __Session Revocation for Private Cloud__: Administrators now have the…

Originalquelle(öffnet in neuem Tab)Problem melden

Angaben zum Datum

Datum aus der Quelle.

Erstmals gesehen am .

Auth0

Sender-constrained Tokens mit DPoP im Early Access

Auth0 unterstützt im Early Access die Bindung von Tokens an die anfragende Client-Anwendung per DPoP (RFC9449), um Token-Diebstahl und -Missbrauch zu erschweren, mit SDKs für iOS Swift und Android Kotlin bereits verfügbar.

We are delighted to announce that support for sender constraining tokens using Demonstrating Proof of Possession (DPoP) is now available in Early Access. Demonstrating Proof of Possession (DPoP) as defined in RFC9449, is an application level mechanism for binding tokens issued by Auth0 to the client application that requested that token. This is implemented using asymmetric key cryptography and with keys that are generated and managed by the client application - no public key infrastructure (PKI) is required. Sender constraining tokens using DPoP can be used to mitigate the risk of tokens being used by unauthorised parties if they are intercepted in transit or exfiltrated from applications. This helps to: - enhance security by mitigating against token theft and misuse by unauthorised parties - improve user experience by being able to use longer-lived access tokens without significantly increasing security risk i.e. not requiring frequent user authentication Auth0 will be rolling out SDK support for DPoP for native applications, single page applications, backend server APIs, and Auth0 management: - SDKs for iOS Swift and Android Kotlin are available now. - SDKs for Javascript, React, Python and more are coming soon. To evaluate DPoP for securing your tokens, contact your Auth0 representative. For more details, check out our [product documentation](https://auth0.com/docs/secure/sender-constraining/demonstrating-proof-of-possession-dpop).

Originalquelle(öffnet in neuem Tab)Problem melden

Angaben zum Datum

Datum aus der Quelle.

Erstmals gesehen am .

Auth0

JA3- und JA4-TLS-Fingerprints in Tenant Logs und Actions

JA3- und JA4-TLS-Fingerprints werden nun in Tenant-Logs wie Success Login, Failed Login und Anomaly Detection erfasst und sind in den Actions-Triggern pre-user-registration, post-user-registration und post-login sowie in der Tenant ACL nutzbar.

We have expanded our security telemetry to include **JA3** and **JA4 TLS fingerprints**. **TLS fingerprinting** is a proven technique for identifying client software based on the TLS handshake. - **JA3** is a fingerprinting method that identifies TLS clients based on their connection parameters. - **JA4** refines TLS fingerprinting to make client identification more stable and resilient to small variations. These signals help customers detect and respond to **malicious traffic** faster, identify suspicious client behavior, and correlate related activity across changing IPs and sessions. --- ## **What’s New** **Tenant Logs** JA3 and JA4 fingerprints are now logged in applicable authentication and security events such as **`Success Login`**, **`Failed Login`**, and **`Anomaly Detection`**. **Actions Integration** JA3 and JA4 fingerprints are now available in **Actions** for real-time, custom security responses, but **only in the following triggers**: - `pre-user-registration` - `post-user-registration` - `post-login` **Tenant Access Control List (ACL) Support** You can also use the [Tenant Access Control List](https://auth0.com/docs/secure/tenant-access-control-list) to block specific TLS fingerprints directly by adding a rule. Alternatively, you can combine JA3 and JA4 signals with Actions to apply custom business logic, such as requiring MFA or conditionally denying access. --- ## **Why It Matters**…

Originalquelle(öffnet in neuem Tab)Problem melden