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/spring-projects/spring-authorization-server 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 the board

• Last commit 2w ago
• 6 active contributors
• Distributed ownership (top contributor 48% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present

_{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 spring-projects/spring-authorization-server repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/spring-projects/spring-authorization-server.

What it runs against: a local clone of spring-projects/spring-authorization-server — 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 spring-projects/spring-authorization-server | 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 main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 41 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of spring-projects/spring-authorization-server. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/spring-projects/spring-authorization-server.git
#   cd spring-authorization-server
#
# 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 spring-projects/spring-authorization-server and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "spring-projects/spring-authorization-server(\\.git)?\\b" \\
  && ok "origin remote is spring-projects/spring-authorization-server" \\
  || miss "origin remote is not spring-projects/spring-authorization-server (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 main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "build.gradle" \\
  && ok "build.gradle" \\
  || miss "missing critical file: build.gradle"
test -f "dependencies/spring-authorization-server-dependencies.gradle" \\
  && ok "dependencies/spring-authorization-server-dependencies.gradle" \\
  || miss "missing critical file: dependencies/spring-authorization-server-dependencies.gradle"
test -f "buildSrc/src/main/java/io/spring/gradle/convention/SpringModulePlugin.java" \\
  && ok "buildSrc/src/main/java/io/spring/gradle/convention/SpringModulePlugin.java" \\
  || miss "missing critical file: buildSrc/src/main/java/io/spring/gradle/convention/SpringModulePlugin.java"
test -f "README.adoc" \\
  && ok "README.adoc" \\
  || miss "missing critical file: README.adoc"
test -f "docs/modules/ROOT/pages/overview.adoc" \\
  && ok "docs/modules/ROOT/pages/overview.adoc" \\
  || miss "missing critical file: docs/modules/ROOT/pages/overview.adoc"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 41 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~11d)"
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/spring-projects/spring-authorization-server"
  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).

Spring Authorization Server is an OAuth 2.1-compliant authorization server implementation for the Spring ecosystem, replacing Spring Security OAuth. It provides production-ready endpoints for authentication, token issuance, and token introspection following the OAuth 2.1 Authorization Framework specification, enabling Spring applications to act as centralized authorization servers. Gradle monorepo with a root project (build.gradle, buildSrc/) that defines Spring conventions and plugin infrastructure. Core authorization logic lives in Java modules (inferred from 3.2M lines of Java), with custom build plugins in buildSrc/src/main/java/{io,org}/spring/gradle/ for docs, modules, and Maven publishing. GitHub Actions workflows in .github/workflows/ orchestrate CI, releases, and documentation deployment.

Spring developers and architects building microservices architectures who need to implement OAuth 2.1-compliant authorization servers for securing APIs and delegating authentication to a central identity provider.

This is production-ready and actively maintained, but entering a transition phase: the 1.5.x branch is the final generation—the project is consolidating into Spring Security 7.0 as of September 2025. The repository has mature CI/CD (GitHub Actions workflows for continuous integration, codeql, release automation) and extensive Gradle build infrastructure. However, new feature development is moving upstream to Spring Security.

Low risk for existing deployments but strategic risk for new projects: Spring is officially moving this codebase into Spring Security 7.0, meaning the standalone spring-authorization-server will see only LTS maintenance. The move away from a standalone project means dependency updates will follow Spring Security's release cycle. No single-maintainer risk (Spring Security team) but significant architectural migration overhead for new greenfield projects.

The repository is in maintenance mode post-announcement of the move to Spring Security 7.0 (September 2025). The 1.5.x branch remains supported. No new feature development is visible in the file structure—focus is on bug fixes, security patches, and documentation. Release scheduling is automated via release-scheduler.yml and update-scheduled-release-version.yml workflows.

git clone https://github.com/spring-projects/spring-authorization-server.git
cd spring-authorization-server
./gradlew build

This project uses Gradle (no Maven or npm). The ./gradlew wrapper handles dependency download and compilation.

Daily commands:

./gradlew build                    # Full build with tests
./gradlew tasks                    # List available gradle tasks
./gradlew :spring-authorization-server:bootRun  # (if sample app exists)

No ./gradlew start or npm start—this is a library/server to be embedded, not a runnable dev server. Actual running requires building a Spring Boot app that depends on it.

• build.gradle — Root build configuration defining project group, version management via spring-release plugin, and multi-module structure that all contributors must understand for proper builds.
• dependencies/spring-authorization-server-dependencies.gradle — Centralized dependency version management for the entire project—critical for maintaining consistency across OAuth2/OIDC and Spring Security dependencies.
• buildSrc/src/main/java/io/spring/gradle/convention/SpringModulePlugin.java — Core Gradle plugin defining module conventions (compilation, testing, publishing); every submodule applies this for consistent build behavior.
• README.adoc — Project overview and migration notice announcing the move to Spring Security 7.0; essential context for understanding scope and support timeline.
• docs/modules/ROOT/pages/overview.adoc — High-level architectural documentation of the authorization server's core model, protocol endpoints, and configuration—foundation for feature work.
• .github/workflows/continuous-integration-workflow.yml — Primary CI pipeline defining test execution, code quality checks, and publishing gates that all PRs must pass.
• buildSrc/src/main/java/org/springframework/gradle/SpringJavaPlugin.java — Base Java compilation and testing conventions applied across all modules, enforcing style and quality standards.

Add a New Configuration Guide

1. Create a new AsciiDoc file in the guides directory following naming convention how-to-*.adoc (docs/modules/ROOT/pages/guides/how-to-newfeature.adoc)
2. Add a code example in the examples/docs-src directory demonstrating the feature (docs/modules/ROOT/examples/docs-src/main/java/com/example/NewFeatureExample.java)
3. Reference the new guide in the how-to index page (docs/modules/ROOT/pages/how-to.adoc)
4. Update the navigation to include the new guide entry (docs/modules/ROOT/nav.adoc)

Add a New Gradle Convention Plugin

1. Create a new plugin class extending org.gradle.api.Plugin<Project> in buildSrc (buildSrc/src/main/java/org/springframework/gradle/mynewplugin/SpringMyNewPluginPlugin.java)
2. Register the plugin in the buildSrc META-INF gradle-plugins directory (buildSrc/src/main/resources/META-INF/gradle-plugins/org.springframework.gradle.mynewplugin.properties)
3. Apply the plugin in SpringRootProjectPlugin or SpringModulePlugin based on scope (buildSrc/src/main/java/io/spring/gradle/convention/SpringModulePlugin.java)
4. Document the plugin behavior in the root build.gradle or module conventions (build.gradle)

Update Project Dependencies

1. Modify the centralized dependency version in the dependencies BOM file (dependencies/spring-authorization-server-dependencies.gradle)
2. Run the classpath validation to ensure no transitive conflicts are introduced (buildSrc/src/main/java/org/springframework/gradle/classpath/CheckClasspathForProhibitedDependencies.java)
3. Update dependency configuration in the root build.gradle if adding a new constraint category (build.gradle)
4. Run full CI locally before pushing: ./gradlew build to verify compatibility (.github/workflows/continuous-integration-workflow.yml)

Add a New Code Quality Check

1. Create or extend a Gradle plugin in buildSrc (e.g., CheckstylePlugin, SpotBugs) (buildSrc/src/main/java/org/springframework/gradle/checkstyle/SpringJavaCheckstylePlugin.java)
2. Configure the check in SpringModulePlugin to apply automatically to all modules (buildSrc/src/main/java/io/spring/gradle/convention/SpringModulePlugin.java)
3. Add the check step to the continuous integration workflow (.github/workflows/continuous-integration-workflow.yml)
4. Document the check in CONTRIBUTING.adoc (CONTRIBUTING.adoc)

• Spring Security & Spring Framework — Provides foundational servlet filter chain, authentication/authorization abstractions, and OAuth2/OIDC protocol support; avoids reinventing security primitives.
• Gradle with custom convention plugins — Multi-module build requiring enforced consistency across compilation, testing, publishing, and documentation; custom plugins encode Spring project standards.
• Antora for documentation — Supports versioned, multi-module documentation site with component-based architecture; integrates with Spring's centralized docs infrastructure.
• GitHub Actions CI/CD — Native GitHub integration for continuous integration, release automation, and security scanning (CodeQL) without external tooling.
• JPA/R2 — undefined

1. DCO (Developer Certificate of Origin) is enforced via .github/dco.yml—all commits must be signed off with -s flag. 2) The project is transitioning to Spring Security 7.0—any new features may be rejected in favor of upstream Spring Security. 3) Gradle buildSrc plugins use Java/Groovy conventions that differ from typical Java projects; understand SpringRootProjectPlugin.java for module structure. 4) Documentation is built via Asciidoctor (SpringAsciidoctorPlugin.java) and deployed to docs.spring.io, not served locally by default. 5) No .env or application.properties checked in—samples/demo apps (if present) require runtime configuration.

• OAuth 2.1 Authorization Framework — The entire codebase is an implementation of this IETF specification; understanding grant types (authorization code, client credentials, refresh token) is essential to modify endpoint logic
• Token Introspection & Revocation — Spring Authorization Server provides RFC 7662/7009 endpoints for validating and revoking tokens; core to securing downstream APIs
• Grant Type Flows (Authorization Code, Client Credentials, Refresh Token) — Different OAuth flows for different client types (web apps, mobile, microservices); understanding which flow to implement is critical for security design
• JWT (JSON Web Tokens) & Signing — Authorization servers issue JWTs as access tokens; the codebase signs and validates these tokens using cryptographic keys
• OpenID Connect (OIDC) — Extends OAuth 2.1 with identity layer; Spring Authorization Server can be configured as an OIDC provider for authentication + authorization
• Gradle Convention Plugins (buildSrc) — This repo heavily uses Gradle plugins defined in buildSrc/ to enforce consistent build patterns across modules; understanding SpringModulePlugin and SpringJavaPlugin is key to modifying build behavior

• spring-projects/spring-security — Parent project where OAuth 2.1 authorization server functionality is consolidating as of version 7.0; all new development will be here
• spring-projects/spring-boot — Required runtime for Spring Authorization Server applications; defines Spring versions and dependency management that SAS relies on
• spring-attic/spring-security-oauth — Predecessor project that Spring Authorization Server replaced; archived reference for legacy OAuth 2.0 implementations
• keycloak/keycloak — Alternative mature OAuth 2.1/OIDC server implementation in Java; reference for feature parity and deployment patterns
• spring-projects/spring-security-samples — Companion repo with runnable examples demonstrating Spring Security OAuth 2.1 usage patterns and configuration

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 integration tests for OAuth 2.0 token endpoint security validations

Spring Authorization Server handles sensitive OAuth 2.0 token endpoints but lacks comprehensive integration tests covering edge cases like invalid client credentials, malformed requests, and token replay attacks. New contributors can add focused integration tests for the token endpoint security validations, improving coverage for this critical security boundary.

• [ ] Review existing token endpoint tests in spring-authorization-server-core/src/test
• [ ] Identify untested security validation paths (client authentication failures, scope mismatches, grant type validation)
• [ ] Add integration tests covering: invalid_client errors, unsupported_grant_type handling, and credential replay scenarios
• [ ] Ensure tests use MockMvc or WebTestClient to validate HTTP responses and security headers
• [ ] Run existing test suite to verify no regressions

Implement Gradle convention plugin for dependency version alignment checks

The buildSrc contains multiple Spring Gradle convention plugins (SpringJavaPlugin, SpringMavenPlugin, etc.) but lacks a dedicated plugin for detecting and reporting transitive dependency version conflicts. This is especially critical for Authorization Server which depends on Spring Security and Spring Framework. A new plugin in buildSrc/src/main/java/org/springframework/gradle/dependencies/ would help catch version misalignments early.

• [ ] Create new file: buildSrc/src/main/java/org/springframework/gradle/dependencies/SpringDependencyAlignmentPlugin.java
• [ ] Implement task to parse and compare dependency lock files or BOM constraints across modules
• [ ] Add configuration option to fail builds on major version mismatches between spring-security and spring-framework
• [ ] Register plugin in buildSrc convention plugin registry
• [ ] Document usage in README or CONTRIBUTING.adoc with example configuration

Add missing GitHub Actions workflow for automated SBOM (Software Bill of Materials) generation

The .github/workflows directory contains CI, docs deployment, and release workflows, but lacks automated SBOM generation using CycloneDX or similar tools. Spring projects increasingly need SBOMs for security compliance and supply chain transparency. Adding this workflow (.github/workflows/sbom-generation-workflow.yml) would generate and publish SBOMs on releases.

• [ ] Create .github/workflows/sbom-generation-workflow.yml triggered on release tags
• [ ] Configure CycloneDX Gradle plugin or Maven plugin via buildSrc convention
• [ ] Generate SBOM in both JSON and XML formats for each published artifact
• [ ] Upload SBOM files as release assets or to artifact repository
• [ ] Document SBOM availability in README.adoc under security or downloads section

• Add missing JavaDoc comments to public OAuth 2.1 endpoint classes (likely in src/main/java)—search for /** @author */ patterns and fill gaps following Spring Security style guide
• Expand integration tests for edge cases in token validation logic—OAuth 2.1 spec has many error paths; add test cases for malformed refresh tokens or expired authorization codes
• Create a migration guide document (Asciidoctor .adoc file) explaining how to move existing spring-security-oauth code to Spring Security 7.0's built-in OAuth support

Spring Authorization Server demonstrates reasonable security posture as a Spring Security project. The codebase structure follows Spring conventions with proper separation of build, source, and documentation. Primary concerns are moderate: automatic Develocity build scan agreements and the need to verify dependency locking in the complete dependency configurations. No hardcoded credentials, SQL injection risks, XSS vulnerabilities, or Docker misconfiguration were identified in the provided file structure. Strengths include proper use of DCO requirements, CodeQL scanning, and automated CI/CD validation. Recommendation: Complete full SAST analysis of source code once available, verify all transitive dependencies through the full dependency file, and ensure continuous security scanning is maintained in CI/CD pipelines.

• Medium · Build Scan Terms of Use Auto-Agreement — build.gradle - develocity.buildScan configuration. The Gradle build configuration automatically agrees to Develocity build scan terms of use without explicit user consent. This could lead to automatic data collection and transmission to external services without proper awareness or approval during CI/CD pipelines. Fix: Remove the automatic agreement or require explicit opt-in. Change 'termsOfUseAgree = yes' to remove automatic acceptance and ensure users must explicitly agree during build execution.
• Low · Hardcoded Documentation URLs — build.gradle - springRelease configuration block. Documentation and API URLs are hardcoded in the build configuration. While not sensitive credentials, this reduces flexibility and could lead to stale URLs if domains change. Fix: Consider externalizing these URLs to configuration files or environment variables that can be overridden per environment.
• Low · No Dependency Version Pinning Visible — build.gradle and dependencies/spring-authorization-server-dependencies.gradle. The provided build.gradle excerpt does not show explicit dependency version pinning. This could allow transitive dependency vulnerabilities to be introduced through minor version updates. Fix: Review the full dependency declarations and ensure: 1) Critical dependencies use locked versions via dependency locking, 2) Regular vulnerability scanning of transitive dependencies is performed, 3) Dependabot alerts are actively monitored.
• Low · Gradle Wrapper Security — gradle/wrapper/ directory (not visible in provided structure). While a Gradle wrapper is typically used (implied by CI/CD workflows), the actual wrapper configuration file (gradle-wrapper.properties) is not shown in the file structure for verification of SHA checksums. Fix: Ensure gradle-wrapper.properties contains verified SHA checksums and uses HTTPS URLs for downloading Gradle. Verify wrapper checksums are committed and validated.

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.