Never accept identity from the browser
Email addresses, provider names and completed flags sent by frontend code are user-controlled input. The browser should send only the session reference to your backend. Your backend should retrieve the result through an authenticated server-to-server request and validate the response before creating a local session.
A public status endpoint can improve the UI, but it should reveal no personal data. A completed status is a signal to verify, not proof of identity.
Keep every secret on a trusted server
Provider client secrets and the Login Broker API key belong in server-side configuration. Do not place them in localStorage, frontend environment variables, downloadable mobile applications, logs or example code.
Have a rotation path before an incident. Login Broker tenant settings can replace an API key server-side; after rotation, the old key stops working as soon as the tenant record is saved.
Bind results to the right tenant
In a multi-tenant system, possessing a valid API key must not allow one customer to read another customer’s login. Look up the session within the requesting tenant and confirm the returned tenant name before accepting the email.
This check prevents a valid session reference from becoming a cross-tenant data leak. It should happen even when session IDs are long and difficult to guess.
Expire attempts quickly and clean up state
Login Broker keeps a session readable for ten minutes. Short expiry limits the value of a copied return URL and makes stale attempts fail predictably. Remove login parameters from the browser URL after consuming them so a refresh does not replay the UI flow.
Use a fresh, unpredictable session ID for every attempt. Stop polling on completion, failure, cancellation or timeout, and prevent two completion handlers from racing.
Use narrow data and narrow permissions
Ask providers only for scopes the login needs. If the application requires only an email address, it should not request contacts, files or posting permissions. Store only what the product actually uses.
Login Broker’s application contract is intentionally narrow: a short-lived record holds the provider, status, email when completed, tenant, return URL and creation time. Your application remains responsible for its user profile, authorization rules and long-lived session.
Review checklist
Use this list during implementation and again before launch.
- All secrets are server-side
- The state/session value is unique per attempt
- The result endpoint requires the tenant API key
- The session lookup and response are tenant-scoped
- Only completed, non-expired results are accepted
- A non-empty email is required
- Errors do not expose secrets or provider tokens
- The application creates its own secure session after verification