Concepts

Guardhouse sits between applications that need an identity and APIs that need to decide whether a request is allowed.

Client -- asks to sign in or obtain a token --> Guardhouse
Client <-- receives tokens ------------------- Guardhouse
Client -- sends an access token ------------> API resource
API resource -- validates and authorizes ----> Protected operation

The configuration has three layers:

• Protocol: clients, API resources, scopes, grant types, and tokens
• Identity: users and the authentication methods used to sign them in
• Authorization: scopes, roles, permissions, and application policies

Read Next

• Clients, resources, and scopes explains what to register and how the values relate.
• Tokens and flows explains which OAuth/OIDC flow to use and what each token is for.
• Users, roles, and permissions separates identity-system administration from authorization in your own API.

Standards and Discovery

Guardhouse implements OAuth 2.0 and OpenID Connect endpoints under /connect/*. Applications should use the tenant issuer and its discovery document instead of hard-coding signing-key locations:

https://your-tenant.guardhouse.cloud/.well-known/openid-configuration

The discovery document identifies the issuer, supported capabilities, endpoint URLs, and JSON Web Key Set (JWKS) location.

The Security Boundary

Guardhouse issues and validates identity credentials. The API receiving an access token must still:

• validate the token rather than merely decode it
• require the intended issuer and audience
• reject expired or otherwise invalid tokens
• enforce the access required by the requested operation

Continue with Protect an API for the implementation choices.