authBook/Outline/Foundational answers.md

Foundational Answers

1. Core Principles: What are the core principles you believe every software company should follow when implementing authentication and authorization?
   • More powerful authentication signals to business customers you are designed for them
   • Companies should have ongoing education around security.
   • Following best practices for security - don't do anything funky, you might get it wrong
   • The sneakiest part of good security is Good User Experience
   • Least privilege by default plus easy requesting and granting
2. Common Pitfalls: What are the most common mistakes or oversights you’ve seen companies make in this area?
   • ParentLink:
     • Ease of implementation was prioritized over user experience
     • Users were not the paying customer, so their needs were de-prioritized, ultimately weakening the stickiness of their product.
   • Domo:
     • Custom implementations of standards (even when using a library) can make adding new integrations, service providers, or identity providers a repetitive, slow, laborious and tedious task.
     • Even the most technical enterprises needed hands on help to get SAML integrated correctly.
     • Underinvesting in development can prevent a polished outcome.
     • Need to keep up-to-date on security landscape changes. e.g. third party cookie rule changes, browser and mobile app behavior differences.
   • Storm:
     • Sometimes you don't need the added complexity of OAuth or other standards
   • Weave:
     • Third party auth providers will squeeze you once they know they have you.
     • Using a third party still requires you to have knowledge about all things authentication.
     • Third parties, especially the large and well known ones, are usually larger and more attractive targets for hackers. You end up being a by-stander to your own security.
     • Companies need the ability to end a user's session remotely and revoke their authentication.
     • Audit logs are your friend. They are different from application logs, they log individual actions taken by users rather than generic events.
3. Security First: How do you prioritize security without compromising user experience? Do you have a guiding philosophy or process for balancing these two?
   • The trick to good security without losing user experience is that good user experience can actually encourage good security. Like an open park verses a dark alley.
   • Passkeys are more secure and easier to use for a user. They are a bit more involved to implement.
   • IDPs are the same way, though it can open you up to the security issues of that provider.
4. Industry Standards: Which industry standards (e.g., OAuth, SAML, JWT) do you consider essential? How do you decide which ones to use or recommend to clients?
   • If integrating with any third party systems, be it for user federation, identification, authentication or any other reason, you should use an open industry standard specification.
     • OIDC > SAML (but...):
       • OIDC
         • is newer and uses REST
         • uses OAuth
         • has a fixed definition of standard fields for a user's profile
         • it has highly supported automated exchange of setup info between systems
         • can support custom fields when needed
       • SAML
         • Older and uses SOAP (less well known)
         • Dark corner cases crop up because of its long legacy
         • Enterprises LOVE it.
         • Many software products implement SAML before they implement OIDC
         • Customers using an IDP for their users will likely have other SAML integrations and so will be familiar with it.
         • custom fields abound but can cause configuration issues
     • FHIR
       • Essential for authenticating to healthcare data systems within the United States
     • User profiles
       • You should use the OpenID Connect standard claims for all fields of your profiles, you can extend the 'claims' by adding your own, but a large body of engineers have already identified the most common fields for user profiles. No need to re-invent the wheel here.
     • Password storage - Technologies change over time by as of the time of this writing bcrypt is my preferred password storage, but some regulatory bodies still require PBKDF2.
       • Bcrypt - stores a salt, hash, the iteration count and all things needed in a standard format that can fit in a text field in a database. It does not require special implementations that can go wrong. In Golang it is as simple as it can get with just a single call to create a hash and a single call to validate a hash.
       • PBKDF2 - is a fantastic and secure way to store your passwords. But I've experienced a few non-standard formats for storage which made it hard to make interops between new and old systems. Regulatory bodies have been known to require this type of password storage in order to work with their systems. Usually, they have more standardized specifications for you to implement when working with them.