Core Concepts
Understanding Guardian’s core concepts will help you effectively integrate and configure the authentication platform.
Tenant
Section titled “Tenant”A Tenant represents an isolated organization, workspace, or customer account within the authentication platform.
Each tenant has its own users, settings, authentication methods, identity policies, and registered clients. This multi-tenant architecture allows Guardian to serve multiple organizations from a single deployment while maintaining complete logical isolation between tenants.
Client
Section titled “Client”A Client is an application registered within a tenant that needs to authenticate users or obtain tokens from the identity provider.
Clients fall into two categories:
First-Party Client: An application owned and fully trusted by the tenant. These clients authenticate users directly through the identity provider’s API, without involving OAuth 2.0 or OIDC redirect-based flows.
Third-Party Client: An external or partner application that connects to the tenant’s identity provider using standard OpenID Connect (OIDC) and OAuth 2.0 authorization flows.
Clients determine how an application interacts with the tenant’s identity platform, either through direct authentication APIs for trusted internal apps or through OIDC and OAuth 2.0 flows for external applications. Each client includes configuration such as allowed scopes, redirect URIs, and other application settings.
OpenID Connect (OIDC)
Section titled “OpenID Connect (OIDC)”OpenID Connect is an identity layer built on top of OAuth 2.0. Guardian implements OpenID Connect Core 1.0, providing:
- Discovery Endpoint: Enables automatic discovery of OIDC configuration
- UserInfo Endpoint: Retrieve user profile information
- JWKS Endpoint: Public keys for token verification
- ID Tokens: Signed JWT tokens containing user identity information
- Standard Scopes: Support for
openid,email,phone, and custom scopes
OIDC enables single sign-on (SSO) and allows applications to verify user identity and obtain basic profile information in a standardized way.
A Scope defines the permissions or access rights that a client can request. Scopes determine what user information (claims) will be included in tokens and what actions the client can perform.
Guardian supports:
- Standard OIDC Scopes:
openid,email,phonewith predefined claim requirements - Custom Scopes: Tenant-defined scopes with custom claims
- Client-Scope Mapping: Each client can be configured with specific allowed scopes
Scopes are requested during authentication and presented to users during consent flows.
A Flow represents the authentication journey type in Guardian:
- SIGNIN: Authenticate an existing user
- SIGNUP: Register a new user
- SIGNINUP: Combined flow that signs in if the user exists, or signs up if they don’t exist
Flows are particularly relevant for passwordless and social authentication, where the same endpoint can handle both sign-in and sign-up scenarios based on user existence.