| name | cloud-identity-and-auth |
| description | Identity, authentication, authorization, and token management for cloud platforms. Covers Keystone-style scoped tokens, OAuth 2.0 flows, OpenID Connect, JWT structure and pitfalls, federation with SAML/OIDC, service-to-service auth with mTLS and SPIFFE, principle of least privilege, IAM role design, and the service catalog pattern (public/internal/admin endpoints). Use when designing authn/authz for a multi-tenant cloud service, integrating with an identity provider, or reviewing IAM policies for over-privilege. |
| type | skill |
| category | cloud-systems |
| status | stable |
| origin | tibsfox |
| modified | false |
| first_seen | "2026-04-12T00:00:00.000Z" |
| first_path | examples/skills/cloud-systems/cloud-identity-and-auth/SKILL.md |
| superseded_by | null |
Cloud Identity and Authentication
Identity is the bedrock of cloud security. Every API call, every internal RPC, every resource access must ultimately be attributable to a principal — a user, a service account, a workload — and must be authorized against a policy that the platform enforces uniformly. Getting this layer right is what separates a cloud platform from a collection of servers. Getting it wrong is the source of most breach post-mortems. This skill covers the core concepts and failure modes a cloud-systems practitioner has to handle.
Agent affinity: hamilton-cloud (IAM at AWS scale), vogels (service-to-service identity in SOA), lamport (formal reasoning about capability and delegation)
Concept IDs: cloud-keystone-auth, cloud-security-groups-policies, cloud-requirements-tracing
The Three Questions
Every identity system answers three questions in order:
- Authentication (authn). Who are you? Prove it.
- Authorization (authz). What are you allowed to do?
- Accounting. What did you do? (Audit logs.)
Separating these cleanly is the first design decision. Authentication produces an attested identity (a token, a certificate, a signed assertion). Authorization consumes that identity and a resource reference and returns allow/deny. Accounting records both.
The Keystone Model: Scoped Tokens
OpenStack Keystone — and most cloud platforms that followed — use a scoped token model. A user authenticates and requests a token scoped to a project (or tenant, or organization). The token carries:
- The user's identity
- The project scope
- The roles granted to the user in that scope
- An expiration time
- A signature
Every downstream service (Nova, Neutron, Cinder, etc.) validates the token against Keystone and then consults its own policy file to determine whether the user's roles permit the requested action. The token is the authentication; the service's policy engine is the authorization.
The Service Catalog Pattern
A scoped token also carries a service catalog — a list of endpoints the user can reach. Each service has three interface types:
- public. Internet-accessible endpoint (what external clients see).
- internal. Datacenter-internal endpoint, often different network path.
- admin. Operator-only endpoint for management and diagnostics.
Separating these by URL (not just by authz check) adds a network layer defense: even if someone acquires credentials, they need to be on the admin network to hit the admin endpoint.
