first version of the knowledge base :)
This commit is contained in:
65
20 - Knowledge/security/identity-and-authentication.md
Normal file
65
20 - Knowledge/security/identity-and-authentication.md
Normal file
@@ -0,0 +1,65 @@
|
||||
---
|
||||
title: Identity and Authentication
|
||||
description: Core concepts and patterns for identity, authentication, and authorization in self-hosted systems
|
||||
tags:
|
||||
- security
|
||||
- identity
|
||||
- authentication
|
||||
category: security
|
||||
created: 2026-03-14
|
||||
updated: 2026-03-14
|
||||
---
|
||||
|
||||
# Identity and Authentication
|
||||
|
||||
## Summary
|
||||
|
||||
Identity and authentication define who or what is requesting access and how that claim is verified. In self-hosted environments, a clear identity model is essential for secure remote access, service-to-service trust, and administrative control.
|
||||
|
||||
## Why it matters
|
||||
|
||||
As environments grow, per-application local accounts become hard to manage and harder to audit. Shared identity patterns reduce duplicated credentials, improve MFA coverage, and make access revocation more predictable.
|
||||
|
||||
## Core concepts
|
||||
|
||||
- Identity: the user, service, or device being represented
|
||||
- Authentication: proving that identity
|
||||
- Authorization: deciding what the identity may do
|
||||
- Federation: delegating identity verification to a trusted provider
|
||||
- MFA: requiring more than one authentication factor
|
||||
|
||||
## Practical usage
|
||||
|
||||
Common self-hosted patterns include:
|
||||
|
||||
- Central identity provider for user login
|
||||
- SSO using OIDC or SAML for web applications
|
||||
- SSH keys or hardware-backed credentials for administrative access
|
||||
- Service accounts with narrowly scoped machine credentials
|
||||
|
||||
Example pattern:
|
||||
|
||||
```text
|
||||
User -> Identity provider -> OIDC token -> Reverse proxy or application
|
||||
Admin -> VPN -> SSH key or hardware-backed credential -> Server
|
||||
```
|
||||
|
||||
## Best practices
|
||||
|
||||
- Centralize user identity where possible
|
||||
- Enforce MFA for admin and internet-facing accounts
|
||||
- Separate human accounts from machine identities
|
||||
- Review how account disablement or key rotation propagates across services
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- Leaving critical systems on isolated local accounts with no lifecycle control
|
||||
- Reusing the same credentials across multiple services
|
||||
- Treating authentication and authorization as the same problem
|
||||
- Forgetting account recovery and break-glass access paths
|
||||
|
||||
## References
|
||||
|
||||
- [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html)
|
||||
- [NIST Digital Identity Guidelines](https://pages.nist.gov/800-63-3/)
|
||||
- [Yubico developer documentation](https://developers.yubico.com/)
|
||||
Reference in New Issue
Block a user