96 lines
3.4 KiB
Markdown
96 lines
3.4 KiB
Markdown
# 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
|
|
*
|