# List of topics that this book can cover

1. [Authentication](./Authentication.md)
2. [Authorization](./Authorization.md)
3. [OAuth](./OAuth.md)
4. [OpenID](./OpenID.md)
5. [SAML](./SAML.md)
6. [JWT](./JWT.md)
7. [SAML vs OAuth vs OpenID](./SAML%20vs%20OAuth%20vs%20OpenID.md)
8. [OAuth vs OpenID](./OAuth%20vs%20OpenID.md)


## Questions I need to answer before attempting to write this book

1. Do I strictly focus on authentication or expand it to authorization and security in general?
2. 

## Topics

### Why listen to this guy?

### What this book is

### What this book is not

### What are you authenticating?

  * Users
  * Anonymous
  * System services
  * Third parties
  * Distributed and decentralized applications

### What are you authenticating for?

  * Shoppers - allowing a user to save and access their information for future use
  * Security - applying authorization (including Paid access or limiting ability to administrate)
  * Paid access - limiting access to paid users
  * User tracking - do we really need to do this?

### How are you authenticating

  * Something you know
  * Something you have
  * Something you are
  * 

### Layers of security

The following list was derived from https://identitymanagementinstitute.org/layered-security-model/

  * Physical security
  * Network security
  * Application security (you are here!)
  * Data security
  * User education on security

### Developer Experience

  * Consider the experience of a developer who has to apply your authentication
  * Compare to physical security, when you make an area well lit, highly visible, and easily accessible the place by default becomes more secure when compared to a dark hidden ally-way. You didn't need to add a security guard.
  * When your authentication infrastructure is easy to apply or applied by default, your application automatically becomes more secure.

### User Experience

  * Consider the user experience as a way of making your application more secure (see also physical security comparison in developer experience)
  * Why passwords are still useful
    * Familiarity - people have used passwords in many applications, it isn't new to them
    * Ease of use (unless done right) - example of FHIR client
    * Ease of implementation - low barrier to entry
    * Inexpensive (unless hacked)
    * Scalability
    * No specialized hardware
    * Versatility (standalone, or as part of a mfa system, or versatility in how it is implemented)
    * User choice (choosing their own passwords)
    * Encourages users to be aware of their security
    * Ease of recovery
    * User autonomy - users have full control over their passwords, changing them when they want
  * Why passwords should die
    * Weak passwords
    * Password reuse
    * Phishing vulnerability
    * Credential Stuffing - using stolen creds to gain access
    * Password management challenges - putting all passwords into a single basket (pw manager)
    * Brute-force attacks
    * Password recovery risks - security questions, email resets etc can be susceptible to social engineering
    * Limited security - it is a single factor (something you know)
    * Support costs - the trade-off you get because of the low cost of implementation
    * Password Policy Complexity
    * User Resistance
    * Password hash storage
    * Limited accountability - sharing of passwords
    * Less convenience compared to biometrics or other technology
  * The case for WebAuthn and other asymmetric cryptographic authentication
    *