Auth module upgrade

:new: We’ve completed updates to the Auth module for generated backend applications. This is the first major update to this module in the last 2 years, including an overhaul of the module’s mechanisms, business process blocks, and middleware. Although it was not easy, the changes are worth it.

  • New business process blocks for handling registration, user authentication, password reset, and recovery.
  • Business process blocks for secure generation of confirmation and recovery tokens with protection against brute force attacks.
  • A new Probe block for checking user creds without creating a session.
  • A new block for session management, Get Current Session (in addition to Get Current User).
  • Blocks for working with Passkey (FIDO2).
  • Support for ECDSA session signatures in authorized server requests with optional request body hashing.

Important changes:
All Auth module business process blocks are not intended for direct connection to endpoints: they no longer automatically obtain the current user - no more magic under the hood. Old business process blocks are marked as Deprecated and will eventually be removed (3-6 months).
A user’s session can now have multiple states, depending on the module settings and user profile.

  • A Confirmed flag in the user profile and module will prevent endpoints from being called unless they have the Skip Confirmation flag. Why: This allows protecting endpoints until the user confirms their email or phone number.
  • A 2FA flag in the user profile and session, which will prevent endpoints from being called if 2FA is enabled in the profile but not yet in the session. Endpoints have a Skip 2FA flag. Why: This allows protecting endpoints from incomplete user authorization.

A Prebuilt Examples folder has been added to the business process, where we have compiled several examples of authorization use.

Along with the updated Auth module for the backend, updates for endpoint settings were also released:

  • A new Client/Server Signatures flag for enabling the verification of client ECDSA signatures in requests and responses from the server with optional request body hashing.
  • A new Encryption flag for enabling the encryption of request and response bodies using AES-GCM-256, Perfect Forward Secrecy, and deriving a common request key based on ECDH.

Of all the new functionality, Passkey, session and client signatures, encryption cannot yet be used - we are waiting for support in clients.