66 lines
2.2 KiB
Markdown
66 lines
2.2 KiB
Markdown
---
|
|
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/)
|