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.