Applications and API resources

Guardhouse separates the software requesting a token from the API accepting that token:

• A client represents a browser app, native app, or service.
• A resource represents a protected API and defines its token audience.
• A scope represents a capability a client may request for that resource.

Create resources and scopes before clients so each client receives only the access it needs.

Choose a client type

Client type	OAuth flow	Credentials	Use it for
SPA	Authorization Code with PKCE	Public client; no client secret	Browser applications
Native	Authorization Code with PKCE	Public client; no client secret	Mobile and desktop applications
Service	Client Credentials	Confidential client with a secret	Backends, jobs, and service-to-service calls

The client type determines the supported flow and cannot be treated as a cosmetic label. Create a separate client when an application needs a different flow, trust boundary, or environment.

Native clients can also record Android package and SHA-256 fingerprint values or an iOS bundle and team ID. Supply each platform pair together when your mobile association setup requires it.

Register an API resource

In the dashboard, open Applications → Resources and create a resource:

1. Enter a recognizable name.
2. Choose an audience that uniquely identifies the API.
3. Select the API resource type for an ordinary protected API. Use other resource types only when the corresponding product capability is enabled for your deployment.
4. Add scopes with stable names and descriptions, such as an API-specific read or write capability.

Choose the audience carefully. APIs compare it with the access token audience, and changing it requires coordinated application and API updates.

The resource details page supplies the issuer, signing algorithm, and JWKS URL needed for local JWT validation.

Create and configure a client

Open Applications → Clients, choose the client type, and then configure the client:

• Redirect URIs are the exact destinations Guardhouse may use after sign-in.
• Post-logout URIs are the permitted destinations after logout.
• Allowed origins permit browser calls from specific origins; they do not grant API access.
• Access-token lifetime controls how long issued access tokens remain valid.
• Refresh tokens and their lifetime should be enabled only when the application needs continued access.
• Resources and scopes limit what the client may request.

Use exact production HTTPS values. Scheme, hostname, port, path, case, and trailing slash can all affect URI matching. Avoid wildcard origins and keep localhost entries in development clients only.

Client secrets

Service-client and introspection secrets are confidential and may only be displayed when created or rotated. Copy them once into a production secret store. Never place them in a browser, mobile package, source repository, or log.

Grant System API access only when required

System API access permits administrative automation for users, roles, and permissions. Grant it only to a dedicated service client, request only the required scopes, and keep the client separate from ordinary application traffic.

See System API access credentials for the supported public API workflow.

Choose a token-validation method

Local JWT validation

Most APIs should validate access tokens locally:

1. Load the issuer metadata and signing keys from Guardhouse.
2. Validate the signature and signing algorithm.
3. Validate issuer, audience, expiry, and not-before time.
4. Enforce the scopes and user authorization required by the endpoint.

Use the issuer, audience, and JWKS values shown on the resource page rather than constructing URLs.

Token introspection

Use introspection when an API must ask Guardhouse for current token state. Enable it on the resource, copy the generated resource client ID and secret, and keep those credentials on the API backend.

Resource introspection credentials identify the API performing validation. They are not interchangeable with an application client's secret.

Production checklist

• Use separate clients and secrets for development, staging, and production.
• Assign only the resources and scopes each client needs.
• Test login, logout, refresh, and invalid-token behavior.
• Test issuer and audience validation before accepting traffic.
• Record owners and a rotation procedure for every secret.
• Rotate a secret immediately if it is exposed, then update all authorized callers.