auth-design

Topics in the source

• Auth design
• 1. Do not build authentication from scratch
• 2. Choose sessions or tokens deliberately
• 3. Get the cookie and token handling right
• 4. Design authorization around objects, not just roles
• 5. Enforce in one place
• 6. Make it observable and recoverable
• Report

Two separate problems, constantly conflated, with different failure modes: Authentication: who is this? Mature, well-solved, and you should use a library Authorization: what may they do? Application-specific, and where nearly all real breaches originate Teams spend most of their effort on the first because it is visible, and most of their vulnerabilities live in the second. Object-level authorization is the one to get right. Password handling, session fixation, timing attacks, reset flows, and MFA are all solved and all easy to get subtly wrong. Use the platform's framework, or an identity provider. If you are storing passwords yourself, use argon2id or bcrypt with the current cost parameters, never a general-purpose hash, never with a hand-rolled salt. The flows people forget to secure, which are attacked precisely because they are afterthoughts: password reset, email change, account recovery, and MFA enrolment. A reset flow is a login bypass if the token is guessable, does not expire, or is reusable. Done when: every path that can establish a session has been enumerated and secured. | | Server sessions | JWTs | | --- | --- | --- | | Revocation | Immediate | Not possible before ex

This is an excerpt. Refer to the complete source and its current requirements.