Connect Auth0, Azure AD (Entra), Google OAuth, or local credentials. The built-in Backend-for-Frontend pattern handles token exchange and issues secure, HttpOnly session cookies — keeping tokens off the client entirely.
Each application runs in one of two authentication modes. In Enterprise mode, users must be provisioned by an administrator before they can use the application, and there's no anonymous access at all — a good fit for internal tools where access is controlled centrally. In B2C mode, users self-register the first time they sign in through a supported identity provider, and the application can optionally allow anonymous visitors to read records that have been marked as readable by anyone.
Instead of a browser app obtaining and storing a bearer token itself, the Backend-for-Frontend layer logs the user in, holds the resulting token server-side, and hands the browser only an opaque session cookie. That cookie is HttpOnly, so client-side script can never read it, and it's only ever sent over HTTPS. From then on, the app calls the BFF's proxy endpoints instead of the core API directly, and the BFF attaches the stored token on the app's behalf — JavaScript never touches a token at any point in the flow.
Logging in can happen through an identity provider redirect, through VividEcho's own local username-and-credential login, or by exchanging a token you already hold (handy for tools like Postman) for a session cookie.