Auth0
What's Changing:
We are fixing an issue where Auth0 was including an empty login_hint query parameter when redirecting users to external identity providers. Going forward, login_hint will only be included in the authorization request when a value is actually present.
Why This Matters: Some external OAuth providers strictly validate request parameters and reject authorization requests that contain empty parameter values. This caused authentication failures for customers whose upstream identity providers do not tolerate empty login_hint values — particularly in scenarios where customers do not control the external IdP and cannot modify its validation behavior.
Rollout Timing: This fix will be rolled out progressively over the next 1–2 weeks.
Action Required: No action is required from customers. If you previously implemented a workaround by overriding connection parameters to suppress the empty login_hint, you may optionally remove that override after confirming the fix is active in your environment.
We're excited to announce that Resend is now Generally Available as an out-of-the-box email delivery provider in Auth0!
With this release, you can now configure Resend as your email delivery provider with built-in configuration directly within Auth0. Resend offers a modern, developer-friendly approach to transactional email with excellent deliverability and a clean API.
Check out our documentation for detailed setup instructions.
Have questions or suggestions? Reach out to us in our community channel and we'd love to hear how Resend is working for you!
This feature is available on all Auth0 plans.
We are excited to announce Auth for MCP is now Generally Available.
Auth for MCP gives you a straightforward way to add authentication and authorization to any MCP server, so you control exactly who gets access, and what they get access to. Implement authentication, CIMD registration, and OBO token exchange for AI agents.
Auth for MCP is a product capability that uses the combination of the following features:
Client ID Metadata (CIMD) Registration (GA)
For MCP clients to connect to MCP servers, they need to identify themselves. But how does a server trust a new client it's never seen? The MCP spec solves this by recommending the use of CIMD: each client hosts a document containing its metadata at a URL that identifies the client. In Auth0, tenant admins provide that URL, and Auth0 fetches the metadata, validates it, and displays it for confirmation before creating the client. You get control over which clients can access your MCP server ensuring no surprise registrations.
On-Behalf-Of Token Exchange (GA)
After a user's agent authenticates with an MCP server and issues a request, it needs to call another API like a Salesforce instance or HR system to finish the job. The question is: how does that second API know the request is legitimate and who it's actually for? On-Behalf-Of Token Exchange lets MCP servers trade the user’s access token for one that works with the downstream API, scoped correctly and still tied to the original user. No shared secrets, no service accounts with too much power. And full auditing and visibility into every action.
Resource Parameter Compatibility Mode (GA)
The MCP spec uses "resource" identifiers to indicate which server an agent wants to talk to, rather than the "audience" parameter that OAuth has traditionally used. Auth0 now supports this natively, allowing MCP implementations to stay spec-compliant without workarounds or translation layers.
Enhanced Security Controls for Third-Party Applications (GA)
As you open your APIs to AI agents, partners, and developer ecosystems, third-party applications need to be secure by default. The recently shipped Enhanced Security Controls gives third-party apps a production-ready, secure-by-default posture, with the control you need over what external applications can access.
Documentation Links
What's Changing:
We are fixing an issue where Auth0 was including an empty login_hint query parameter when redirecting users to external identity providers. Going forward, login_hint will only be included in the authorization request when a value is actually present.
Why This Matters: Some external OAuth providers strictly validate request parameters and reject authorization requests that contain empty parameter values. This caused authentication failures for customers whose upstream identity providers do not tolerate empty login_hint values — particularly in scenarios where customers do not control the external IdP and cannot modify its validation behavior.
Rollout Timing: This fix will be rolled out progressively over the next 1–2 weeks.
Action Required: No action is required from customers. If you previously implemented a workaround by overriding connection parameters to suppress the empty login_hint, you may optionally remove that override after confirming the fix is active in your environment.
We are excited to announce Auth for MCP is now Generally Available.
Auth for MCP gives you a straightforward way to add authentication and authorization to any MCP server, so you control exactly who gets access, and what they get access to. Implement authentication, CIMD registration, and OBO token exchange for AI agents.
Auth for MCP is a product capability that uses the combination of the following features:
Client ID Metadata (CIMD) Registration (GA)
For MCP clients to connect to MCP servers, they need to identify themselves. But how does a server trust a new client it's never seen? The MCP spec solves this by recommending the use of CIMD: each client hosts a document containing its metadata at a URL that identifies the client. In Auth0, tenant admins provide that URL, and Auth0 fetches the metadata, validates it, and displays it for confirmation before creating the client. You get control over which clients can access your MCP server ensuring no surprise registrations.
On-Behalf-Of Token Exchange (GA)
After a user's agent authenticates with an MCP server and issues a request, it needs to call another API like a Salesforce instance or HR system to finish the job. The question is: how does that second API know the request is legitimate and who it's actually for? On-Behalf-Of Token Exchange lets MCP servers trade the user’s access token for one that works with the downstream API, scoped correctly and still tied to the original user. No shared secrets, no service accounts with too much power. And full auditing and visibility into every action.
Resource Parameter Compatibility Mode (GA)
The MCP spec uses "resource" identifiers to indicate which server an agent wants to talk to, rather than the "audience" parameter that OAuth has traditionally used. Auth0 now supports this natively, allowing MCP implementations to stay spec-compliant without workarounds or translation layers.
Enhanced Security Controls for Third-Party Applications (GA)
As you open your APIs to AI agents, partners, and developer ecosystems, third-party applications need to be secure by default. The recently shipped Enhanced Security Controls gives third-party apps a production-ready, secure-by-default posture, with the control you need over what external applications can access.
Documentation Links
We're excited to announce that Resend is now Generally Available as an out-of-the-box email delivery provider in Auth0!
With this release, you can now configure Resend as your email delivery provider with built-in configuration directly within Auth0. Resend offers a modern, developer-friendly approach to transactional email with excellent deliverability and a clean API.
Check out our documentation for detailed setup instructions.
Have questions or suggestions? Reach out to us in our community channel and we'd love to hear how Resend is working for you!
This feature is available on all Auth0 plans.
We are excited to announce Auth for MCP is now Generally Available.
Auth for MCP gives you a straightforward way to add authentication and authorization to any MCP server, so you control exactly who gets access, and what they get access to. Implement authentication, CIMD registration, and OBO token exchange for AI agents.
Auth for MCP is a product capability that uses the combination of the following features:
Client ID Metadata (CIMD) Registration (GA)
For MCP clients to connect to MCP servers, they need to identify themselves. But how does a server trust a new client it's never seen? The MCP spec solves this by recommending the use of CIMD: each client hosts a document containing its metadata at a URL that identifies the client. In Auth0, tenant admins provide that URL, and Auth0 fetches the metadata, validates it, and displays it for confirmation before creating the client. You get control over which clients can access your MCP server ensuring no surprise registrations.
On-Behalf-Of Token Exchange (GA)
After a user's agent authenticates with an MCP server and issues a request, it needs to call another API like a Salesforce instance or HR system to finish the job. The question is: how does that second API know the request is legitimate and who it's actually for? On-Behalf-Of Token Exchange lets MCP servers trade the user’s access token for one that works with the downstream API, scoped correctly and still tied to the original user. No shared secrets, no service accounts with too much power. And full auditing and visibility into every action.
Resource Parameter Compatibility Mode (GA)
The MCP spec uses "resource" identifiers to indicate which server an agent wants to talk to, rather than the "audience" parameter that OAuth has traditionally used. Auth0 now supports this natively, allowing MCP implementations to stay spec-compliant without workarounds or translation layers.
Enhanced Security Controls for Third-Party Applications (GA)
As you open your APIs to AI agents, partners, and developer ecosystems, third-party applications need to be secure by default. The recently shipped Enhanced Security Controls gives third-party apps a production-ready, secure-by-default posture, with the control you need over what external applications can access.
Documentation Links
We're excited to announce that Resend is now Generally Available as an out-of-the-box email delivery provider in Auth0!
With this release, you can now configure Resend as your email delivery provider with built-in configuration directly within Auth0. Resend offers a modern, developer-friendly approach to transactional email with excellent deliverability and a clean API.
Check out our documentation for detailed setup instructions.
Have questions or suggestions? Reach out to us in our community channel and we'd love to hear how Resend is working for you!
This feature is available on all Auth0 plans.
What's Changing:
We are fixing an issue where Auth0 was including an empty login_hint query parameter when redirecting users to external identity providers. Going forward, login_hint will only be included in the authorization request when a value is actually present.
Why This Matters: Some external OAuth providers strictly validate request parameters and reject authorization requests that contain empty parameter values. This caused authentication failures for customers whose upstream identity providers do not tolerate empty login_hint values — particularly in scenarios where customers do not control the external IdP and cannot modify its validation behavior.
Rollout Timing: This fix will be rolled out progressively over the next 1–2 weeks.
Action Required: No action is required from customers. If you previously implemented a workaround by overriding connection parameters to suppress the empty login_hint, you may optionally remove that override after confirming the fix is active in your environment.
We are excited to announce Auth for MCP is now Generally Available.
Auth for MCP gives you a straightforward way to add authentication and authorization to any MCP server, so you control exactly who gets access, and what they get access to. Implement authentication, CIMD registration, and OBO token exchange for AI agents.
Auth for MCP is a product capability that uses the combination of the following features:
Client ID Metadata (CIMD) Registration (GA)
For MCP clients to connect to MCP servers, they need to identify themselves. But how does a server trust a new client it's never seen? The MCP spec solves this by recommending the use of CIMD: each client hosts a document containing its metadata at a URL that identifies the client. In Auth0, tenant admins provide that URL, and Auth0 fetches the metadata, validates it, and displays it for confirmation before creating the client. You get control over which clients can access your MCP server ensuring no surprise registrations.
On-Behalf-Of Token Exchange (GA)
After a user's agent authenticates with an MCP server and issues a request, it needs to call another API like a Salesforce instance or HR system to finish the job. The question is: how does that second API know the request is legitimate and who it's actually for? On-Behalf-Of Token Exchange lets MCP servers trade the user’s access token for one that works with the downstream API, scoped correctly and still tied to the original user. No shared secrets, no service accounts with too much power. And full auditing and visibility into every action.
Resource Parameter Compatibility Mode (GA)
The MCP spec uses "resource" identifiers to indicate which server an agent wants to talk to, rather than the "audience" parameter that OAuth has traditionally used. Auth0 now supports this natively, allowing MCP implementations to stay spec-compliant without workarounds or translation layers.
Enhanced Security Controls for Third-Party Applications (GA)
As you open your APIs to AI agents, partners, and developer ecosystems, third-party applications need to be secure by default. The recently shipped Enhanced Security Controls gives third-party apps a production-ready, secure-by-default posture, with the control you need over what external applications can access.
Documentation Links
What's Changing:
We are fixing an issue where Auth0 was including an empty login_hint query parameter when redirecting users to external identity providers. Going forward, login_hint will only be included in the authorization request when a value is actually present.
Why This Matters: Some external OAuth providers strictly validate request parameters and reject authorization requests that contain empty parameter values. This caused authentication failures for customers whose upstream identity providers do not tolerate empty login_hint values — particularly in scenarios where customers do not control the external IdP and cannot modify its validation behavior.
Rollout Timing: This fix will be rolled out progressively over the next 1–2 weeks.
Action Required: No action is required from customers. If you previously implemented a workaround by overriding connection parameters to suppress the empty login_hint, you may optionally remove that override after confirming the fix is active in your environment.
We're excited to announce the new CMD+K Command Palette functionality is now available to all users in the Auth0 dashboard. Get instant access to navigation, quick actions and recently visited pages all from a single keyboard shortcut.
What’s new:
- Globally available: Always accessible from any page by entering CMD+K.
- Quick navigation: Jump to any page, feature, or setting without leaving the keyboard.
- Recently visited: Have your last 3 visited pages available at the top.
- Action shortcuts: Execute common tasks directly from the palette.
- Contextual actions: Get tasks specific to pages right in CMD+K.
To keep improving this experience, we’ll be continuously adding more contextual actions and capabilities to the CMD+K Command Palette.
Private Key JWT assertions and expanded signing algorithm support are now generally available across Enterprise Okta and OIDC Connections.
Private Key JWT assertions deliver enterprise-grade security by leveraging asymmetric cryptography to authenticate against your upstream Okta and OIDC identity providers. You now have full control over which signing algorithms Auth0 uses when generating client assertion JWTs - giving you the flexibility to align with your security standards and existing infrastructure.
We've also expanded ID token verification on enterprise connections to support additional signing algorithms: RS384, RS512, PS256, PS384, ES256, and ES384. This means fewer integration headaches when connecting to upstream identity providers and greater compatibility across your authentication flows.
These capabilities put you in the driver's seat: choose the cryptographic methods that work best for your environment, eliminate integration blockers, and stay ahead of evolving security standards.
Please refer to the product documentation.
Private Key JWT assertions and expanded signing algorithm support are now generally available across Enterprise Okta and OIDC Connections.
Private Key JWT assertions deliver enterprise-grade security by leveraging asymmetric cryptography to authenticate against your upstream Okta and OIDC identity providers. You now have full control over which signing algorithms Auth0 uses when generating client assertion JWTs - giving you the flexibility to align with your security standards and existing infrastructure.
We've also expanded ID token verification on enterprise connections to support additional signing algorithms: RS384, RS512, PS256, PS384, ES256, and ES384. This means fewer integration headaches when connecting to upstream identity providers and greater compatibility across your authentication flows.
These capabilities put you in the driver's seat: choose the cryptographic methods that work best for your environment, eliminate integration blockers, and stay ahead of evolving security standards.
Please refer to the product documentation.
We're excited to announce the new CMD+K Command Palette functionality is now available to all users in the Auth0 dashboard. Get instant access to navigation, quick actions and recently visited pages all from a single keyboard shortcut.
What’s new:
- Globally available: Always accessible from any page by entering CMD+K.
- Quick navigation: Jump to any page, feature, or setting without leaving the keyboard.
- Recently visited: Have your last 3 visited pages available at the top.
- Action shortcuts: Execute common tasks directly from the palette.
- Contextual actions: Get tasks specific to pages right in CMD+K.
To keep improving this experience, we’ll be continuously adding more contextual actions and capabilities to the CMD+K Command Palette.
Private Key JWT assertions and expanded signing algorithm support are now generally available across Enterprise Okta and OIDC Connections.
Private Key JWT assertions deliver enterprise-grade security by leveraging asymmetric cryptography to authenticate against your upstream Okta and OIDC identity providers. You now have full control over which signing algorithms Auth0 uses when generating client assertion JWTs - giving you the flexibility to align with your security standards and existing infrastructure.
We've also expanded ID token verification on enterprise connections to support additional signing algorithms: RS384, RS512, PS256, PS384, ES256, and ES384. This means fewer integration headaches when connecting to upstream identity providers and greater compatibility across your authentication flows.
These capabilities put you in the driver's seat: choose the cryptographic methods that work best for your environment, eliminate integration blockers, and stay ahead of evolving security standards.
Please refer to the product documentation.
We're excited to announce the new CMD+K Command Palette functionality is now available to all users in the Auth0 dashboard. Get instant access to navigation, quick actions and recently visited pages all from a single keyboard shortcut.
What’s new:
- Globally available: Always accessible from any page by entering CMD+K.
- Quick navigation: Jump to any page, feature, or setting without leaving the keyboard.
- Recently visited: Have your last 3 visited pages available at the top.
- Action shortcuts: Execute common tasks directly from the palette.
- Contextual actions: Get tasks specific to pages right in CMD+K.
To keep improving this experience, we’ll be continuously adding more contextual actions and capabilities to the CMD+K Command Palette.
We're excited to announce the new CMD+K Command Palette functionality is now available to all users in the Auth0 dashboard. Get instant access to navigation, quick actions and recently visited pages all from a single keyboard shortcut.
What’s new:
- Globally available: Always accessible from any page by entering CMD+K.
- Quick navigation: Jump to any page, feature, or setting without leaving the keyboard.
- Recently visited: Have your last 3 visited pages available at the top.
- Action shortcuts: Execute common tasks directly from the palette.
- Contextual actions: Get tasks specific to pages right in CMD+K.
To keep improving this experience, we’ll be continuously adding more contextual actions and capabilities to the CMD+K Command Palette.
Private Key JWT assertions and expanded signing algorithm support are now generally available across Enterprise Okta and OIDC Connections.
Private Key JWT assertions deliver enterprise-grade security by leveraging asymmetric cryptography to authenticate against your upstream Okta and OIDC identity providers. You now have full control over which signing algorithms Auth0 uses when generating client assertion JWTs - giving you the flexibility to align with your security standards and existing infrastructure.
We've also expanded ID token verification on enterprise connections to support additional signing algorithms: RS384, RS512, PS256, PS384, ES256, and ES384. This means fewer integration headaches when connecting to upstream identity providers and greater compatibility across your authentication flows.
These capabilities put you in the driver's seat: choose the cryptographic methods that work best for your environment, eliminate integration blockers, and stay ahead of evolving security standards.
Please refer to the product documentation.
Private Key JWT assertions and expanded signing algorithm support are now generally available across Enterprise Okta and OIDC Connections.
Private Key JWT assertions deliver enterprise-grade security by leveraging asymmetric cryptography to authenticate against your upstream Okta and OIDC identity providers. You now have full control over which signing algorithms Auth0 uses when generating client assertion JWTs - giving you the flexibility to align with your security standards and existing infrastructure.
We've also expanded ID token verification on enterprise connections to support additional signing algorithms: RS384, RS512, PS256, PS384, ES256, and ES384. This means fewer integration headaches when connecting to upstream identity providers and greater compatibility across your authentication flows.
These capabilities put you in the driver's seat: choose the cryptographic methods that work best for your environment, eliminate integration blockers, and stay ahead of evolving security standards.
Please refer to the product documentation.