Guardhouse integrations

Integrate identity into the stack you already use.

Use official SDKs or standards-based OAuth and OpenID Connect for web, mobile, backend, service, and agent workloads. Guardhouse runs sign-in, sessions, and token infrastructure. Your application keeps control of routes, access rules, and user experience.

View Integration Documentation

Choose an integration path

What are you building?

Start with the workload your team needs to protect. Each path explains the recommended flow, where Guardhouse fits, and the application work that remains.

Web application

Keep user passwords out of your application

Recommended path
Use @guardhouse/react for a React SPA, or a maintained OpenID Connect client for another web framework.
Recommended authentication flow
Authorization Code with PKCE through Guardhouse-hosted sign-in.

Guardhouse handles

  • Hosted sign-in, signup, recovery, MFA, passkeys, and social-provider communication
  • OAuth authorization, token issuance, refresh, logout, and session infrastructure
  • Tenant branding and configured identity policies

Your team implements

  • Register exact redirect and logout URLs and request only the scopes the app needs
  • Restore the client session and decide how protected screens behave
  • Send the access token to APIs that independently enforce authorization

Mobile application

Use the system browser, a registered callback, and platform secure storage

Recommended path
Use the beta @guardhouse/react-native SDK, or a maintained native OpenID Connect client.
Recommended authentication flow
Authorization Code with PKCE for a public native client; never embed a client secret.

Guardhouse handles

  • Hosted authentication and the OAuth/OIDC protocol endpoints
  • Token issuance, refresh, revocation, and hosted-browser passkey authentication
  • Identity-provider and account-security flows

Your team implements

  • Register an exact deep-link callback for iOS and Android
  • Install and configure the SDK browser and secure-storage dependencies
  • Restore the session before choosing authenticated or signed-out UI

Backend API

Validate every bearer token at the API boundary

Recommended path
Use Guardhouse.SDK for ASP.NET Core, @guardhouse/node for Express, guardhouse for Python, or a standards-compatible validation library.
Recommended authentication flow
Local JWT signature validation or remote token introspection.

Guardhouse handles

  • Token issuance, discovery metadata, signing keys, and introspection status
  • Configured API audiences, OAuth scopes, roles, and permissions
  • Client and resource credential rotation controls

Your team implements

  • Validate issuer, audience, lifetime, and signature or active state
  • Enforce the scope, role, permission, or application policy for each operation
  • Choose the latency and revocation trade-off between JWT validation and introspection

Worker or service

Use a separate client and narrow scopes for every service

Recommended path
Use the .NET, Node.js, or Python token client, or call the standard OAuth token endpoint.
Recommended authentication flow
Client Credentials for a confidential backend or service client.

Guardhouse handles

  • Service-client registration, scope grants, token issuance, and revocation
  • API resources and audiences shared with user-facing applications
  • Client registrations and scope grants for each workload and environment

Your team implements

  • Store client secrets in server-side secret storage and rotate them when required
  • Cache tokens until renewal is necessary instead of requesting one per job or call
  • Authorize the service at the target API using narrow scopes

AI agent or MCP server

Authenticate agents and protect MCP services with OAuth

Recommended path
Register the agent as a confidential OAuth client and the MCP or HTTP service as an API resource. Use Client Credentials only when the workload acts on its own behalf.
Recommended authentication flow
Validate the resulting token at the protected service with JWT/JWKS or introspection.

Guardhouse handles

  • OAuth client identity, scoped token issuance, and token status
  • API audiences and operation-specific scopes
  • The same access-control platform used by applications and services

Your team implements

  • Keep credentials out of prompts, traces, model context, and browser code
  • Validate tool inputs and apply authorization after token validation
  • Add approval, rate limits, and downstream safeguards appropriate to each action

Official SDKs

Choose the SDK for your runtime

Choose by runtime and trust boundary: browser, mobile, API, or service. Each guide covers the appropriate authentication flow and token-validation method.

.NET and ASP.NET Core

Guardhouse.SDK
Generally available
Use it for
ASP.NET Core APIs, workers, service clients, System API automation, and webhook receivers.
Runtime
.NET 6 through .NET 10

Install

dotnet add package Guardhouse.SDK

What it provides

  • Client Credentials with in-memory token caching and optional refresh
  • JWT/JWKS and introspection resource-server validation
  • Typed clients for documented user, role, and permission operations
  • HMAC webhook-signature validation

React

@guardhouse/react
Generally available
Use it for
Browser applications using Guardhouse-hosted authentication.
Runtime
React 18 and later

Install

npm install @guardhouse/react

What it provides

  • Authorization Code with PKCE
  • Provider and authentication hooks
  • Protected UI helpers and session restoration
  • Access-token retrieval and refresh when configured

Note: The browser package does not expose the System API and must never receive a client secret.

React Native

@guardhouse/react-native
Beta
Use it for
iOS and Android applications using hosted sign-in.
Runtime
React Native 0.70+, React 18+, Node.js 18+ tooling

Install

npm install @guardhouse/react-native react-native-keychain react-native-inappbrowser-reborn

What it provides

  • System-browser Authorization Code with PKCE
  • Deep-link callback handling
  • Keychain or Keystore-backed refresh-token storage
  • Session restoration and token refresh

Note: Hosted-browser passkeys are supported. The beta SDK's headless passkey method requires explicit deployment support. The SDK guide contains setup because no separate quickstart is published.

Node.js

@guardhouse/node
Beta
Use it for
Express APIs, workers, and confidential service clients.
Runtime
Node.js 18 and later; Express 4 middleware

Install

npm install @guardhouse/node express

What it provides

  • Client Credentials with process-local token caching
  • Express bearer-token middleware
  • JWT/JWKS and introspection validation
  • Generic authenticated HTTP helpers for trusted backend calls

Note: Use the documented /api/v1 routes for administration. The Node.js SDK does not provide typed coverage for every System API operation.

Python, FastAPI, and Flask

guardhouse
Beta
Use it for
Python workers and APIs built with FastAPI or Flask.
Runtime
Python 3.9 and later

Install

Core SDK

pip install guardhouse "pydantic>=2"

FastAPI

pip install guardhouse[fastapi]

Flask

pip install guardhouse[flask] "pydantic>=2"

What it provides

  • Client Credentials and process-local token caching
  • JWT/JWKS and introspection verification
  • FastAPI dependencies and Flask decorators
  • Generic authenticated HTTP helpers

Note: Prefer the asynchronous client APIs during beta. Framework integrations use optional install extras. No separate quickstart is published; use the SDK guide for setup.

On the SDK roadmap

Planned language SDKs

Go, Java, and PHP SDKs are planned and are not available today. Until then, use a maintained OAuth 2.0 or OpenID Connect library for sign-in and token handling.

Guardhouse can review a language-specific SDK or integration request and help a trusted backend connect to the documented System API.

Need a language-specific integration reviewed? Request integration help .

  • Go Planned
  • Java Planned
  • PHP Planned

Standards-based integration

Use standard protocols when an SDK is not the right fit

Guardhouse SDKs handle common setup for supported runtimes. Other stacks can use maintained OAuth 2.0 and OpenID Connect libraries. APIs can validate tokens with JWT/JWKS or introspection.

This reduces the amount of Guardhouse-specific code in your application. Tenant configuration, hosted sign-in, and SDK helpers remain Guardhouse-specific.

OAuth 2.0 and OpenID Connect
Use discovery metadata and maintained libraries when an official Guardhouse SDK is not the right fit.
Authorization Code with PKCE
Web and mobile applications redirect to hosted sign-in without collecting the user password or shipping a client secret.
Client Credentials
Workers, services, and agents can authenticate as themselves with narrow API scopes. MCP servers validate tokens when they act as protected resources.
Refresh tokens
Eligible clients can renew delegated access without another sign-in when offline access is enabled.
JWT and JWKS
APIs can validate tokens locally without adding a Guardhouse request to every protected operation.
Token introspection and revocation
APIs can query Guardhouse for current token status when faster revocation awareness matters, at the cost of a network request.

Working code

See one practical example for each SDK

These short examples show one integration outcome. Open the linked guide for the current package API, client registration, configuration, failure handling, and production checks. Replace placeholder values with registered test configuration before running an example.

React

Configure Guardhouse-hosted authentication at the React application root. 

import { GuardhouseProvider } from "@guardhouse/react";

function OrdersApp() {
  return <main>Orders application</main>;
}

export function App() {
  return (
    <GuardhouseProvider
      config={{
        authority: "https://your-tenant.guardhouse.cloud",
        clientId: "YOUR_BROWSER_CLIENT_ID",
        redirectUri: window.location.origin,
        audience: "YOUR_API_AUDIENCE",
      }}
    >
      <OrdersApp />
    </GuardhouseProvider>
  );
}

.NET

Validate Guardhouse access tokens in an ASP.NET Core API. 

using Guardhouse.SDK.Extensions;
using Guardhouse.SDK.Models;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddGuardhouseResource(options =>
{
    options.Authority = "https://your-tenant.guardhouse.cloud";
    options.Audience = "orders_api";
    options.ValidationMode = TokenValidationMode.JwtSignature;
});

builder.Services.AddAuthorization();

var app = builder.Build();

app.UseAuthentication();
app.UseAuthorization();

app.MapGet("/orders", () => Results.Ok(new[] { "order-1001" }))
   .RequireAuthorization();

app.Run();

Node.js

Protect an Express route and require an API scope. 

import express from "express";
import { guardhouseMiddleware } from "@guardhouse/node";

const app = express();

app.use(
  "/api/orders",
  guardhouseMiddleware({
    authority: "https://your-tenant.guardhouse.cloud",
    audience: "orders_api",
    requiredScopes: ["orders.read"],
  }),
);

app.get("/api/orders", (_request, response) => {
  response.json({ orders: [] });
});

app.listen(3000);

Python

Add introspection-backed authentication to FastAPI. 

from fastapi import Depends, FastAPI
from guardhouse.middleware import User, requires_auth

app = FastAPI()
get_caller = requires_auth(
    authority="https://your-tenant.guardhouse.cloud",
    audience="orders_api",
    validation_mode="introspection",
    introspection_client_id="YOUR_RESOURCE_CLIENT_ID",
    introspection_client_secret="YOUR_RESOURCE_CLIENT_SECRET",
)

@app.get("/orders")
async def orders(caller: User = Depends(get_caller)):
    return {"subject": caller.sub, "orders": []}

React Native

Start hosted mobile sign-in with an exact deep-link callback. 

import { GuardhouseClient } from "@guardhouse/react-native";

const client = new GuardhouseClient({
  authority: "https://your-tenant.guardhouse.cloud",
  clientId: "YOUR_NATIVE_CLIENT_ID",
  redirectUri: "com.example.app://callback",
});

export async function signIn() {
  return client.loginWithBrowser();
}

Integration architecture

Guardhouse handles identity while your application keeps business authorization

User-facing applications redirect to Guardhouse for sign-in. Services request tokens as confidential clients. In both cases, your API validates the token and makes the authorization decision.

User sign-in

Authorization Code with PKCE

  1. 01 User
  2. 02 Application
  3. 03 Hosted auth
  4. 04 Access token
  5. 05 Protected API

The application never collects the Guardhouse password. The API validates every token and the required authorization before serving a protected operation.

Service access

Client Credentials

  1. 01 Service or agent
  2. 02 Credentials
  3. 03 Guardhouse
  4. 04 Scoped token
  5. 05 Protected API

Each workload keeps its secret in server-side storage, reuses tokens until renewal, and receives only the scopes required by the target API.

Identity & communication providers

Use your existing identity and email providers

Guardhouse handles the authentication flow and sends transactional messages through providers you configure. When you use custom providers, your organization owns their accounts and credentials.

Identity providers

Let users sign in with accounts they already use. Guardhouse processes the provider callback and links the external identity to the Guardhouse user.

  • Google
  • Microsoft
  • Apple
  • Facebook

Availability depends on tenant and deployment configuration. When you connect a custom provider, its account and credentials remain under your organization's control. Managed defaults can vary by plan and region.

Transactional email

Send verification, recovery, invitation, security, and passwordless messages through your own email provider.

  • SMTP
  • Postmark
  • SendGrid
  • Amazon SES

Configure and test the sender and templates before enabling email-dependent authentication flows.

Configure providers and webhooks

Webhooks

Send documented user changes to your application

Use webhooks to copy documented user changes into your application. Verify every signature before processing a payload.

Two documented events

Subscribe to UserCreated and UserUpdated. These are the documented events today.

Signed delivery

Validate the HMAC-SHA256 signature and timestamp against the exact raw request body before processing JSON.

Delivery controls

Choose synchronous or asynchronous delivery, configure fixed retries, rotate the secret, and inspect delivery history.

Make receivers idempotent: retries can deliver the same event more than once. Do not use an undelivered webhook as the sole record of critical state.

Administration & automation

Automate supported identity operations from a trusted backend

The versioned /api/v1 System API covers the documented user, role, and permission operations. It uses a high-privilege server-side client and must not be called from browser or mobile code.

Users

  • Create, list, retrieve, and update users
  • Block or unblock access and change a password
  • Assign or remove a role and delete personal data

Roles

  • Create, list, retrieve, and update roles
  • Add or remove role permissions

Permissions

  • Create, list, retrieve, and update permissions

Typed SDK operations

The .NET SDK provides typed clients for documented user, role, and permission operations.

Documented HTTP operations

Trusted backends can call the documented /api/v1 routes with a System API token.

Dashboard configuration

Clients, API resources, branding, providers, and tenant settings remain dashboard configuration rather than this external API.

Read the System API guide Ask about an integration

Integration effort

See what Guardhouse handles and what your team still owns

Guardhouse provides the identity infrastructure and protocol endpoints. Your team still defines access rules and applies them in the application.

Guardhouse handles

Identity infrastructure

  • Hosted sign-in, signup, verification, recovery, MFA, passkeys, and configured social login
  • OAuth and OpenID Connect endpoints, token issuance, signing metadata, introspection, and revocation
  • Session and account infrastructure, user administration, roles, permissions, and scopes
  • Configured identity-provider, email-provider, and webhook communication

Your application handles

Integration and policy

  • Register exact redirect, logout, deep-link, origin, audience, and scope configuration
  • Decide protected-route behavior and enforce authorization at every API operation
  • Design the application's roles, permissions, scopes, and tenant-specific access rules
  • Keep client, introspection, webhook, and provider secrets in appropriate secret storage
  • Validate tokens or use introspection, test failure paths, and monitor the integration in production

Migration & implementation help

Plan the identity cutover around your current architecture

Guardhouse can help evaluate an integration or SDK request. The migration guide covers user transfer, password compatibility, token and session cutover, and gradual or direct migration. It does not promise an automatic or zero-downtime move.

  1. Inventory the existing boundary

    Map applications, redirect URLs, APIs, service identities, roles, providers, and current user records before choosing a cutover model.

  2. Choose gradual or direct cutover

    A staged migration can move applications independently. A direct cutover reduces parallel operation but concentrates testing and user communication.

  3. Account for user and session constraints

    Password compatibility, user transfer, existing access tokens, refresh tokens, and active sessions depend on the source system and may require reauthentication.

Open the migration guide Discuss your integration

Continue evaluating

Check the product, price, and operating model

  • Features

    Review authentication, authorization, user management, and machine identity.

    Explore features

  • Pricing

    Compare plans, included usage, and current feature packaging.

    Compare pricing

  • Security & deployment

    Assess token security, shared responsibilities, Cloud, and self-hosting.

    Review security

Integrations FAQ

Questions engineering and procurement teams ask

Find the right SDK, understand beta status, and review mobile, M2M, provider, and migration limits.

Which SDK should we use?

Choose by runtime and trust boundary: React for browser UI, React Native for mobile, .NET for ASP.NET Core and .NET workers, Node.js for Express and Node workers, and Python for Python services or FastAPI and Flask APIs. Node.js, React Native, and Python are currently beta.

Can Guardhouse work without an official SDK?

Yes. Guardhouse exposes OAuth 2.0 and OpenID Connect discovery and protocol endpoints. Use a maintained standards-compatible client for your stack, and contact Guardhouse if you need help with the integration.

Can Guardhouse protect an existing API?

Yes. Register the API as a resource with its audience and scopes, validate bearer tokens with JWT signatures or introspection, and enforce the required scope, role, permission, or policy on each protected operation.

Does Guardhouse support mobile applications?

Yes. Native clients use Authorization Code with PKCE and an exact registered callback. The beta React Native SDK adds system-browser login, secure token storage, session restoration, and refresh handling.

How do service-to-service applications authenticate?

Create a confidential client for each workload and environment, grant only the required API scopes, keep the secret in server-side storage, and use Client Credentials. Cache the returned token until renewal is necessary.

Can Guardhouse protect AI agents and MCP servers?

Yes. Register an agent as a confidential OAuth client when it acts on its own behalf, and register the MCP or HTTP service as an API resource. Validate the token at the protected service and enforce operation-specific scopes. This is standards-based API protection, not a separate agent protocol.

Can we use our existing identity providers?

Guardhouse currently documents Google, Microsoft, Apple, and Facebook social sign-in. Provider availability depends on tenant and deployment configuration, and each provider must be configured and tested before rollout.

Are the SDKs open source?

Yes. The official .NET, JavaScript, and Python SDK repositories are public and licensed under Apache 2.0.

Which SDKs are beta?

Node.js, React Native, and Python are beta. Pin and test a version before upgrading. .NET and React are documented as stable and are labeled generally available on this page.

Can Guardhouse help us migrate?

Guardhouse can review the target integration. User transfer, password compatibility, token and session cutover, and gradual versus direct migration depend on the source architecture. The migration guide describes the current path without promising automatic or zero-downtime migration.

Choose an SDK or a standards-based path.

Start with an official SDK, follow the OAuth/OIDC guides, or contact us to review a custom stack.

View Documentation Contact Us