Skip to content
bohewuPublic

About

Self-hosted Identity Provider built with .NET 10 and OpenIddict. Features: OIDC/OAuth 2.0, MFA (TOTP/Email/Passkey), Admin Dashboard, Docker deployment, SQL Server/PostgreSQL support.

Topics

Resources

Contributing

Security policy

Stars

4 stars

Watchers

0 watching

Forks

Latest commit

 

History

1,670 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

HybridAuth IdP

A robust, enterprise-ready Identity Provider (IdP) built on .NET 10+ and OpenIddict, featuring a hybrid SSR (Razor Pages) and SPA (Vue.js) architecture.

Caution

SECURITY WARNING: This project includes default development passwords (e.g., YourStrong!Passw0rd). Never use these in production. Always use Environment Variables or a Secret Manager to override sensitive settings.


📖 Documentation


🏗️ Project Structure

  • Core.Domain: Entities, constants, and core business models.
  • Core.Application: Interfaces, DTOs, and application logic.
  • Infrastructure: Data access (EF Core), external services, and security implementations.
  • Web.IdP: The main Identity Provider host (Razor Pages + Vue.js Admin UI).
  • samples/: Sample integration clients (M2M, Device Flow, Impersonation).
  • Tests/: Comprehensive test suites (System, Integration, Unit).

🚀 Key Features

🔐 OpenID Connect & OAuth 2.0

Powered by OpenIddict:

  • Flows: Authorization Code + PKCE, Client Credentials, Device Flow.
  • Security: Refresh token rotation with configurable reuse leeway, secure session management.
  • Standard Discovery: Full OIDC metadata at /.well-known/openid-configuration.

🛡️ Admin & Identity Management

  • RBAC: Hierarchical roles and fine-grained permissions.
  • Impersonation: Secure "Login As" feature for administrative support.
  • Observability: Prometheus metrics and structured audit logging.
  • Bot Protection: Integrated Cloudflare Turnstile support.
  • External Identity: Seamless integration with Google & Microsoft accounts, including auto-linking and AMR support.
  • External data sources: Configure approved query inputs separately from profile synchronization output field mappings; independent producers implement the public non-login contracts.
  • Branding: Customizable UI with configurable Privacy Policy and Help documentation links.
  • First administrator: Disabled-by-default, one-time operational bootstrap for genuinely fresh deployments; see the deployment guidance.

🛠️ Tech Stack

  • Backend: .NET 10+, EF Core (SQL Server/PostgreSQL), OpenIddict, SignalR.
  • Frontend: Vue.js 3, Vite, Tailwind CSS, Headless UI.
  • Testing: xUnit, FluentAssertions, Playwright, Vitest.

⚡ Quick Start

Development

  1. Prerequisites: Docker Desktop, .NET 10 SDK+.
  2. Run Infrastructure:
    docker compose -f docker-compose.dev.yml up -d
  3. Run App:
    dotnet run --project Web.IdP

Production Deployment

Fresh installations: use the Setup Wizard:

cd deployment
./setup-env.ps1  # or ./setup-env.sh

This generates certificates, passwords, and configuration for a new deployment. Existing deployments must preserve their original .env; do not rerun the wizard to regenerate it. See Deployment Guide for startup instructions.

Upgrading 1.4.x Legacy API Deployments to 1.6.x

The new application no longer reads LegacyAuth__*; configure Provider Proof 1.0 independently. Before switching images, verify the producer's exact namespace and that every selected Legacy key is the same opaque stable subject returned by that authority. With a verified restorable backup, use the one-time SQL Server backfill to add the new provider binding to the original UserId. Schema migration does not backfill these links.

Keep the original .env, Legacy links, existing accounts and their MFA/Passkey/recovery data. A matching username, email or GUID-shaped key is not identity proof. Follow the existing-account upgrade procedure for preview, apply, minimal configuration changes and rollback.

Clients displaying user names must request, be allowed, and be granted the OIDC profile scope, then reauthorize. In 1.6.x, name and preferred_username require profile; a custom employee-id scope does not imply it. sub remains the local UserId, and token claim nesting is unchanged. See the client compatibility note.


⚖️ License

Distributed under the MIT License. See LICENSE for more information.


🤖 AI-Assisted Development

This project was developed with significant assistance from advanced AI coding agents. While following industry standards, we recommend a secondary human security audit for production environments. Code is provided "AS IS".

About

Self-hosted Identity Provider built with .NET 10 and OpenIddict. Features: OIDC/OAuth 2.0, MFA (TOTP/Email/Passkey), Admin Dashboard, Docker deployment, SQL Server/PostgreSQL support.

Topics

Resources

Contributing

Security policy

Stars

4 stars

Watchers

0 watching

Forks

Releases

Packages

Used by

Contributors

Languages