Identity and Access Management

Built-in authenticators are generally available. You can now configure multi-factor authentication (MFA) requirements for login as. Your employees and customers can access Salesforce through their Slack app. You can authorize access to Einstein Bot APIs with a connected app. And the OAuth 2.0 JWT bearer flow for server-to-server integration now supports high assurance settings. For enhanced security, users can no longer log in to Salesforce by using a username and password as URL query string parameters to the login URL.

  • Built-In Authenticators as a Verification Method Are Now Generally Available
    With new support for biometric methods, it’s easier to verify identity in Salesforce. Your users can register biometric built-in authenticators such as Touch ID, Face ID, and Windows Hello. When users are challenged to verify their identity, including for multi-factor authentication and device activations, they get a prompt to use their built-in authenticator. Built-in authenticators are generally available.
  • Salesforce Support Users, Partner Support Users, and Subscribers with High-Assurance Sessions Bypass Multi-Factor Authentication During Log In As
    To streamline user support, Salesforce support users, partner support users, and subscribers with high-assurance sessions can log in as other users without triggering multi-factor authentication (MFA) challenges. The Multi-Factor Authentication for UI Logins During Log In As setting enforces MFA only for support users and subscribers who don’t have high-assurance sessions.
  • Let Users Access Salesforce with Slack Credentials
    Simplify your users’ login experience by enabling single sign-on (SSO) with a Slack authentication provider. With this SSO solution, your users can log in to your Salesforce org or Experience Cloud site with their Slack credentials, saving them time and clicks. They can also access their protected Slack data in Salesforce.
  • Give Authorized Access to Einstein Bot APIs
    To authorize access to Einstein Bot APIs, you can assign a connected app the new chatbot_api OAuth scope. With this scope, the connected app is authorized to make service calls to Bot APIs over a public network.
  • JWT Bearer Flow Supports High Assurance Sessions
    The OAuth 2.0 JWT bearer flow for server-to-server integration now supports high assurance settings. Previously, high assurance settings in user profiles weren’t passed to access tokens retrieved during the JWT bearer flow.
  • Disable Users from Logging Into an Org or Experience Cloud Site with Login Credentials as URL Query String Parameters (Release Update)
    To improve security, users can no longer log in to Salesforce by using a username and password as URL query string parameters to the login URL. Any users who try to do so are redirected to the login page. This update was first made available in Winter ’22 and is enforced in Spring ’22.
  • Securely Update Email Addresses and Reset Passwords (Release Update)
    To ensure the security of your org, users must now reset their password before your changes to their email address and password become active. When a user resets the password using the provided link, the new email address is activated. Previously, the user’s email address became active as soon as you saved the change. This update was first made available in Summer ’21 and is enforced in Spring ’22.
  • Bypass MFA Challenges for Single Sign-On Auth Provider Logins (Release Update)
    This release update enforces the documented behavior of bypassing MFA challenges for users who are assigned the user permission Multi-factor Authentication for User Interface Logins. This update was first made available in Winter ’22 and is enforced in Spring ’22.
  • Manage Single Sign-On User Mappings
    To ensure that users are mapped correctly between Salesforce and a third-party identity provider, use the Auth.ConfirmUserRegistrationHandler interface.
  • Use a SAML Digest Algorithm Based on Your Request Signature Method
    New SAML single sign-on (SSO) service provider configurations with a third-party identity provider use a digest algorithm based on the Request Signature Method (RSM). With this update, you can improve security and you still have the option to use SHA1 to ensure that existing SSO and SLO configurations don’t break. Previously, all configurations used SHA1 as the default digest algorithm, regardless of the RSM.

https://help.salesforce.com/s/articleView?id=release-notes.rn_security_auth_and_identity.htm&release=236&type=5