If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/openiddict/openiddict-core shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across all four use cases

• Last commit 1w ago
• 10 active contributors
• Apache-2.0 licensed
• CI configured
• ⚠ Concentrated ownership — top contributor handles 74% of recent commits
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live openiddict/openiddict-core repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/openiddict/openiddict-core.

What it runs against: a local clone of openiddict/openiddict-core — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in openiddict/openiddict-core | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch dev exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 38 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of openiddict/openiddict-core. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/openiddict/openiddict-core.git
#   cd openiddict-core
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of openiddict/openiddict-core and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "openiddict/openiddict-core(\\.git)?\\b" \\
  && ok "origin remote is openiddict/openiddict-core" \\
  || miss "origin remote is not openiddict/openiddict-core (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify dev >/dev/null 2>&1 \\
  && ok "default branch dev exists" \\
  || miss "default branch dev no longer exists"

# 4. Critical files exist
test -f "Directory.Build.props" \\
  && ok "Directory.Build.props" \\
  || miss "missing critical file: Directory.Build.props"
test -f "Directory.Packages.props" \\
  && ok "Directory.Packages.props" \\
  || miss "missing critical file: Directory.Packages.props"
test -f "OpenIddict.slnx" \\
  && ok "OpenIddict.slnx" \\
  || miss "missing critical file: OpenIddict.slnx"
test -f ".github/workflows/build.yml" \\
  && ok ".github/workflows/build.yml" \\
  || miss "missing critical file: .github/workflows/build.yml"
test -f "eng/Build.props" \\
  && ok "eng/Build.props" \\
  || miss "missing critical file: eng/Build.props"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 38 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~8d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/openiddict/openiddict-core"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

OpenIddict is a flexible OAuth 2.0 and OpenID Connect framework for .NET that enables developers to build custom identity servers, clients, and token validators. It natively supports multiple flows (authorization code, implicit, hybrid, client credentials, device authorization, token exchange) and provides out-of-the-box data store implementations for Entity Framework Core, Entity Framework 6, and MongoDB. Monorepo structure with core OAuth/OIDC logic in the root, multiple storage provider implementations (EntityFrameworkCore, EntityFramework, MongoDb packages implied from README), and reference samples in a separate openiddict-samples repository. Build system uses MSBuild with centralized properties in Directory.Build.props and Directory.Build.targets, with multi-targeting support via eng/Build.props.

.NET backend developers and architects building custom OAuth 2.0/OpenID Connect identity providers or integrating OAuth clients into ASP.NET Core (2.3+), ASP.NET 4.6.2+, or cross-platform applications (Android, iOS, macOS, Windows). Also targets developers who need fine-grained control over authentication/authorization flows rather than turnkey solutions.

Actively maintained and production-ready. The repo contains comprehensive CI/CD pipelines (.github/workflows/build.yml, .github/workflows/push.yml), professional build infrastructure (eng/ directory with Version.Details.xml and Signing.props), and follows semantic versioning. The large codebase (8.2MB of C#) and extensive protocol support indicate mature, battle-tested code.

Low risk for actively maintained code, but the framework nature means implementation complexity falls on consumers—incorrect custom code can introduce security vulnerabilities. The repo depends on EF Core/EF6/MongoDB which have their own maintenance timelines. Single organization (openiddict) maintains this, so organizational pivot would be a consideration for enterprise adoption.

Active development indicated by CI/CD pipelines and professional build infrastructure. The repo contains issue templates for bug reports, enhancements, and provider-specific issues (.github/ISSUE_TEMPLATE/), suggesting ongoing community engagement. Versioning infrastructure in eng/Version.Details.xml indicates regular release cycles.

git clone https://github.com/openiddict/openiddict-core.git
cd openiddict-core
./build.sh

Or on Windows: Build.cmd. The project uses NuGet (NuGet.config present) and supports MSBuild-based builds.

Daily commands: For development: ./build.sh (Linux/macOS) or Build.cmd (Windows). For CI/CD: pipelines are defined in .github/workflows/build.yml and .github/workflows/push.yml. The solution file is OpenIddict.slnx (using Visual Studio 2022+ slnx format).

• Directory.Build.props — Central MSBuild properties file defining shared build configuration, NuGet versioning, and target frameworks for the entire solution.
• Directory.Packages.props — Centralized NuGet package version management using PackageReference; essential for understanding all external dependencies across the monorepo.
• OpenIddict.slnx — Solution file defining the project structure and organization of the 600-file codebase; primary entry point for understanding module relationships.
• .github/workflows/build.yml — CI/CD pipeline definition controlling automated builds, tests, and validation; critical for understanding deployment and quality gates.
• eng/Build.props — Build engineering configuration extending common build infrastructure; defines compiler flags, signing, and versioning strategy specific to OpenIddict.
• .editorconfig — Code style and formatting rules enforced across the codebase; essential for maintaining consistency in PR reviews and local development.

Add a new NuGet package dependency

1. Add the package name and version to the appropriate property group in Directory.Packages.props using ItemGroup with PackageReference (Directory.Packages.props)
2. Reference the package in your project file using the version variable defined in the props file (OpenIddict.slnx)
3. Run build.sh or Build.cmd to restore and validate the dependency (build.sh)

Configure a new build target or platform

1. Add target framework moniker and platform conditionals to Directory.Build.props in the appropriate PropertyGroup (Directory.Build.props)
2. Define platform-specific compiler constants and runtime behavior in eng/Build.props (eng/Build.props)
3. Update the CI build matrix in .github/workflows/build.yml to test the new target framework (.github/workflows/build.yml)
4. If cross-platform compilation is needed, add appropriate cross-compilation scripts under eng/common/cross/ (eng/common/cross/build-rootfs.sh)

Modify code style and formatting rules

1. Update the C# rules in .editorconfig under [*.cs] section or add new language-specific sections (.editorconfig)
2. Document the reasoning and guidelines in a comment block above the rule section (.editorconfig)
3. Run a local build to ensure existing code can be formatted with the new rules, or update code systematically (build.sh)

Add a new issue template for contributors

1. Create a new .yml file in .github/ISSUE_TEMPLATE/ (e.g., feature_request.yml) following the existing template structure (.github/ISSUE_TEMPLATE/bug_report.yml)
2. Define labels, title, body sections, and validation rules in the YAML frontmatter (.github/ISSUE_TEMPLATE/config.yml)
3. Register the template in config.yml under blank_issues_enabled or add routing rules (.github/ISSUE_TEMPLATE/config.yml)

• MSBuild (Directory.Build.props, Directory.Packages.targets) — Centralized build configuration for multi-project .NET solution; enables consistent compilation flags, versioning, and dependency management across OAuth 2.0/OpenID Connect modules.
• GitHub Actions (build.yml, push.yml) — Automated CI/CD for multi-target framework validation (net462, net6.0, net8.0); verifies code quality and compatibility across platforms before merge.
• PackageReference + Directory.Packages.props — Modern NuGet dependency management reducing version conflicts; centralized control simplifies updates for Entity Framework Core, ASP.NET Core, and OpenID Connect libraries.
• .editorconfig — Enforces consistent C# naming, formatting, and style rules across 600+ files; reduces review friction and ensures code quality gates for OAuth/OIDC implementations.
• Cross-compilation scripts (eng/common/cross/) — Supports building on ARM64, ARM, and other architectures; OpenIddict serves Android, iOS, and embedded systems requiring platform-native compilation.

• Monorepo structure with 600 files in a single solution

  • Why: OpenIddict provides client, server, and token validation features across multiple platforms (ASP.NET 4.6.2+, ASP.NET Core 2.3+, Android, iOS, macOS, Windows); centralized development simplifies cross-cutting concerns like OpenID Connect spec compliance.
  • Consequence: Larger build surface area and slower per-commit CI; compensated by parallel target compilation and caching strategies.

• Multiple target frameworks (net462, net6.0, net8.0) tested in CI

  • Why: OpenIddict must support legacy .NET Framework and modern .NET Core consumers; different platforms have different capability and performance profiles.
  • Consequence: Increased CI pipeline duration (~5–10 min per commit); necessary to guarantee backward compatibility and forward innovation.

• Centralized version management via eng/Versions.props and eng/Version.Details.xml

  • Why: OAuth 2.0 and OpenID Connect ecosystems require careful versioning for compliance and security patches; single version source prevents inconsistencies.
  • Consequence: Additional build configuration overhead; offset by reduced merge conflicts in multi-contributor PRs.

• Cross-platform build infrastructure in eng/common/

  • Why: OpenIddict targets Windows, Linux, macOS, and exotic platforms (ARM64 IoT, Tizen); common infrastructure avoids script duplication.
  • Consequence: Complex build scaffolding; enables seamless ARM cross-compilation for embedded OAuth/OIDC use cases.

• Single-platform support (deliberately supports Windows, Linux, macOS, Android, iOS, macOS, Windows Desktop)
• Real-time compliance monitoring (provides static OAuth 2.0/OIDC spec conformance, not runtime telemetry)
• Containerized deployments out-of-box (users integrate into Docker/K8s; repo does not ship container images)
• Graphical UI for configuration (library-based; users build UI atop the APIs)

1. Framework targeting complexity: The project targets multiple frameworks (ASP.NET Core 2.3+, .NET Framework 4.6.2+, plus cross-platform) with shared code—build failures may be framework-specific. 2. Custom store implementations required: Unlike turnkey identity providers, OpenIddict is a framework requiring custom authorization controller code and data store implementation; boilerplate gaps are user responsibility. 3. Certificate/signing requirements: Production packages must be signed (see eng/Signing.props)—local development may require certificate setup. 4. Multi-database compatibility: Tests and samples must validate across EF Core, EF6, and MongoDB—integration tests require multiple databases running locally.

• OAuth 2.0 Authorization Flows (Authorization Code, Implicit, Hybrid, Client Credentials, Device Authorization, Token Exchange) — OpenIddict implements all IETF-standardized flows; understanding which flow applies to your use case (web app vs. mobile vs. server-to-server) is fundamental to correct implementation.
• OpenID Connect (OIDC) Core 1.0 — OpenIddict combines OAuth 2.0 with OpenID Connect for authentication; OIDC adds identity layer (ID tokens, user info endpoints) on top of OAuth—essential to understand the difference.
• Provider/Store Abstraction Pattern — OpenIddict abstracts data storage behind store interfaces (IOpenIddictApplicationStore, etc.) enabling swappable backends (EF Core, EF6, MongoDB, custom); understanding this pattern is critical to extending or customizing OpenIddict.
• JWT (JSON Web Tokens) and JWK (JSON Web Key) Sets — OpenIddict issues JWT access/ID tokens and publishes public keys via OIDC discovery; understanding token structure and cryptographic validation is essential for client implementations and debugging token issues.
• ASP.NET Core Middleware Pipeline and Authentication Handlers — OpenIddict integrates as ASP.NET Core authentication middleware; middleware ordering, custom authentication handlers, and policy-based authorization are required knowledge for implementation.
• Device Authorization Flow (RFC 8628) — OpenIddict natively supports device flow for OAuth on IoT/TV/printers; this flow is fundamentally different from code/implicit flows and requires user verification on a secondary device.
• Token Exchange Grant (RFC 8693) — OpenIddict supports token exchange for scenarios like federation and privilege escalation; understanding token exchange enables advanced multi-party authorization scenarios.

• openiddict/openiddict-samples — Official samples repository demonstrating all OAuth 2.0 and OpenID Connect flows with real working code; essential companion to understand practical usage patterns.
• IdentityServer/IdentityServer4 — Direct alternative for .NET that provides turnkey OAuth/OIDC server with GUI management; OpenIddict explicitly positions itself as the framework alternative.
• IdentityServer/IdentityServer — Successor to IdentityServer4 (now community maintained); another production OAuth/OIDC framework for .NET with different architectural choices.
• aspnet/AspNetCore — ASP.NET Core framework repository; OpenIddict integrates deeply with ASP.NET Core middleware and identity systems, relevant for understanding integration points.
• dotnet/efcore — Entity Framework Core source; OpenIddict depends on EF Core for data access, and deep EF Core knowledge is needed to implement custom stores.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add CodeQL security scanning workflow for .NET-specific vulnerabilities

The repo has eng/common/core-templates/jobs/codeql-build.yml but no active GitHub Actions workflow invoking it. OpenIddict is a security-critical OAuth 2.0/OpenID Connect library where supply chain security is paramount. A dedicated CodeQL workflow monitoring for .NET-specific vulnerabilities (unsafe crypto, injection attacks, improper token validation) would catch regressions early.

• [ ] Create .github/workflows/codeql-analysis.yml based on Microsoft's reference templates
• [ ] Configure language: csharp with appropriate build steps (e.g., dotnet build for OpenIddict.slnx)
• [ ] Integrate with existing eng/common/core-templates/jobs/codeql-build.yml infrastructure
• [ ] Set upload-sarif to true and configure branch protection rules to require passing checks
• [ ] Test against known CVEs (e.g., weak random number generation in token creation)

Add integration tests for OAuth 2.0 Device Authorization Grant flow coverage

The README mentions 'device authorization' support but the file structure shows no dedicated test suite for this flow. Device flow is increasingly important for IoT and CLI tools. Creating comprehensive integration tests would validate compliance with RFC 8628 and catch edge cases around user code validation, device polling intervals, and expiration handling—critical for non-interactive authentication scenarios.

• [ ] Create test/OpenIddict.Tests.Integration/DeviceAuthorizationFlowTests.cs
• [ ] Implement tests for device code generation, user verification URL validation, and polling interval enforcement
• [ ] Add negative tests: expired codes, invalid user codes, mismatched device/user codes
• [ ] Validate that the implementation correctly handles slow user responses and concurrent device requests
• [ ] Verify token exchange after successful user verification matches RFC 8628 Section 3.4

Create provider-specific integration tests for common OAuth 2.0 providers (Google, GitHub, Microsoft)

The .github/ISSUE_TEMPLATE/new_provider.yml suggests provider support is a documented feature, but there's no visible test suite validating OpenIddict client integrations with real-world providers. Adding provider-specific integration tests would increase confidence in compatibility and catch breaking changes in provider APIs early (e.g., Microsoft Graph permission scopes, Google token revocation endpoints).

• [ ] Create test/OpenIddict.Tests.Integration/Providers/ directory with GoogleProviderTests.cs, GitHubProviderTests.cs, MicrosoftProviderTests.cs
• [ ] Each test suite should cover: authorization redirect URL construction, token exchange, token refresh, and scope validation
• [ ] Use environment-based credentials (GitHub Secrets) or mock HTTP responses for CI execution
• [ ] Add tests for provider-specific edge cases (e.g., Google's access_type=offline, GitHub's limited scopes)
• [ ] Document in README.md or CONTRIBUTING.md how to run provider tests locally with test credentials

• Add missing unit tests for edge cases in token validation (RFC 8693 token exchange flow)—the test coverage for cross-provider validation scenarios appears incomplete based on the monorepo size.
• Document custom store implementation patterns with concrete C# examples in the main README—the README mentions Entity Framework/MongoDB but provides no sample store code, leaving new contributors to guess at the IOpenIddictApplicationStore, IOpenIddictTokenStore interfaces.
• Create a troubleshooting guide for common ASP.NET Core middleware ordering issues (OpenIddict auth must register before other middleware)—this is a frequent source of 'nothing works' issues in OAuth implementations.

The OpenIddict project demonstrates a security-conscious approach with a dedicated security policy and coordinated vulnerability disclosure process. However, the analysis is limited by unavailable dependency files and incomplete file contents. The main security risks include: (1) inability to assess dependency vulnerabilities due to missing package files, (2) reliance on email-only security reporting, and (3) incomplete documentation. The project uses a professional build infrastructure with common security controls (eng/Signing.props suggests code signing, CI/CD workflows present). To improve security posture, implement automated dependency scanning, expand vulnerability reporting channels, and ensure comprehensive security documentation in the README and installation guides.

• Medium · Missing Dependency Vulnerability Information — Dependencies (not provided). The dependency/package file content is not provided for analysis. Without access to package files (*.csproj, packages.config, Directory.Packages.props, etc.), it's impossible to identify known vulnerable dependencies or outdated packages that may have security issues. Fix: Provide package dependency files and run security scanning tools like 'dotnet list package --vulnerable' or integrate Dependabot/NuGet security scanning in the CI/CD pipeline to identify vulnerable dependencies.
• Low · Security Policy Reliance on Email — SECURITY.md. The security reporting mechanism relies solely on email (security@openiddict.com) without mentioning alternative secure reporting channels like GitHub Security Advisory or a bug bounty program. This may limit responsible disclosure reach. Fix: Consider implementing GitHub's Security Advisory feature, a dedicated bug bounty platform (HackerOne, Bugcrowd), or a security.txt file as additional reporting channels for security vulnerabilities.
• Low · Incomplete README Security Information — README.md. The README.md file snippet is truncated and doesn't display complete security-related information, implementation guidelines, or secure configuration recommendations for OAuth 2.0/OpenID Connect integration. Fix: Ensure the README includes clear security best practices, configuration guidelines, and warnings about common OAuth 2.0/OpenID Connect misconfigurations.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.