Four common ways a client proves who it is to a server, ordered from least to most secret-sensitive. Each diagram shows the exchange step by step.
01
Basic Authentication
sequenceDiagram
autonumber
participant C as Client
participant S as Server
C->>S: Requests resource
S->>C: Requests username/password
C->>S: Sends username/password
S->>C: Returns resource
Credentials travel in plaintext (Base64-encoded, not encrypted) on every request. Simple to implement, but the password is re-exposed constantly.
Not recommended for production
Secret exposure
02
Token Authentication
sequenceDiagram
autonumber
participant C as Client
participant S as Server
C->>S: User logs in
S->>C: Sends encrypted token
C->>S: Sends request with token
S->>C: Returns resource
The client logs in once, receives a token, then sends that token with every subsequent request instead of the password itself.
Great for SPAs & mobile apps
Secret exposure
03
OAuth Authentication
sequenceDiagram
autonumber
participant C as Client
participant U as User
participant A as Auth Server
participant R as Resource Server
C->>U: Authorization request
U->>C: Authorization grant
C->>A: Authorization grant
A->>C: Access token
C->>R: Access token
R->>C: Returns resource
A dedicated authorization server issues scoped access on the user's behalf, so the client never sees the password — only a limited-permission token.
Google / Facebook login
Secret exposure
04
API Key Authentication
sequenceDiagram
autonumber
participant C as Client
participant S as API Server
participant D as Database
C->>S: Create key
S->>C: Store key
C->>S: Access with key
S->>D: Resource authorized
Each client is issued a unique, static key that identifies and authorizes it. Lightweight, but the key must be rotated and stored carefully since it doesn't expire on its own.
The process of systematically handling chnages to a system
Maintain integrity of a system over time
Automation plays an key role
Puppet
Ansibel
Chef
Salt
Examples
Ansible
Open Source
Declarative configuration
YAML configuration files
No control server needed - but ansible tower available
No agents needed, just python and ssh
Puppet
Declarative configuration
Manage state through a UI
Custom modules use puppet DSL
Pushes chnages to clients using control server and agents installed on clients.
Chef
Procedural configuration
Agent/Server
Uses chef DSL
Salt
Declarative configuration
Agent (minions) /Server (Master) - but can support agentless
Uses YAML
Support for event-driven automation
Note: Idempotent Behavior - is an operation that can be applied multiple times without changing the result beyound the initial application.
E.g. 1 x 1 = 1
- Configuration management tools will avoid reapeating tasks.
- The desired state is maintained even if you run it multiple times.