A login server should be boring. If it is exciting, something has gone wrong. These are seven rules I hold myself to while building ids, and the reason behind each.
1. Redirects match exactly
When an app asks to send someone back after sign-in, the address has to match the registered one character for character. No prefixes, no wildcards, no “close enough”. Sloppy matching is how sign-in codes end up on a stranger’s page.
2. Proof keys for everyone
PKCE (a one-time proof that the app finishing sign-in is the app that started it) is required for every client, including the ones that could technically skip it. A rule with no exceptions is a rule nobody forgets to apply.
3. Compare secrets slowly, on purpose
Every secret, token and code is compared in constant time, so the time a check takes never leaks a hint about how close a guess was.
4. Tenants cannot see each other
In a multi-tenant system, one customer reading another’s data is the worst day you can have. So separation lives in the structure of the database layer, not in a promise that every query remembers to filter correctly.
5. Logos are images, not documents
Branding logos are accepted as ordinary images only, checked by actually decoding them and then re-encoding them. Vector files can carry scripts, and a script on the sign-in page is the one thing that must never happen there.
6. A strict content policy
The sign-in pages run with a tight content-security policy and no inline styles. Branding is delivered as a generated stylesheet of colour values, not a free-text box where someone can paste anything.
7. Write down what happened
Logins, failures, credential changes, key rotations, admin actions: all recorded. When something strange happens, an honest log is the difference between an answer and a guess.
What to take from this
Whatever you run for sign-in, ask of it the same seven questions. The answers tell you a lot about how much to trust it.