Spring Boot Prompt to Configure Spring Security OAuth2 & RBAC

What this prompt does

This prompt asks the AI to configure Spring Security for a Spring Boot [spring_version] API, covering OAuth2, RBAC, and multi-tenant authorization with a test for every rule. It sets up an OAuth2 Resource Server validating JWTs from [auth_provider], role-based access control for [roles], permission-based authorization via custom @PreAuthorize expressions, method-level security with @Secured and @RolesAllowed, multi-tenant isolation so users only reach their [tenant_entity] data, API-key auth for service-to-service calls, per-tier rate limiting, CORS for [frontend_origins], security-event logging, and integration tests for every rule using @WithMockUser and MockMvc — including SecurityConfig, a custom UserDetailsService, and a permission evaluator.

The structure works because authorization is where audits and breaches originate, and getting @PreAuthorize, tenant isolation, and the test-per-rule discipline right early prevents painful rework. The prompt treats a test for each security rule as non-negotiable, which is what keeps the rules from silently regressing. Separating service-to-service API-key auth from user OAuth2 is another deliberate choice, since machine callers and human users have different trust models and should not be forced through the same JWT flow.

When to use it

• You are securing a Spring Boot API with OAuth2 and need JWT validation against [auth_provider].
• You need role and permission-based access with custom @PreAuthorize expressions, not just URL rules.
• You require multi-tenant isolation so users cannot reach another tenant's [tenant_entity] data.
• You have service-to-service calls that need API-key authentication separate from user auth.
• You want a test for every security rule so authorization changes cannot silently regress.
• You need CORS configured precisely for known [frontend_origins].

Example output

Expect a SecurityConfig wiring the OAuth2 Resource Server, a custom UserDetailsService, a permission evaluator, @PreAuthorize expressions for your [roles], tenant-scoping logic for [tenant_entity], API-key filter, rate-limiting setup, CORS config for [frontend_origins], security-event logging, and a suite of MockMvc integration tests using @WithMockUser that assert both allowed and denied access for each rule. The security-event logging is wired in alongside, so login attempts and permission denials leave a trail you can audit rather than disappearing silently when a request is rejected.

Pro tips

• Define [roles] as a real hierarchy so the AI can express role inheritance correctly in the access rules.
• Match [auth_provider] (for example, Keycloak) so JWT issuer, audience, and key validation are configured for your actual provider.
• Make tenant scoping on [tenant_entity] explicit at the query level too; method security alone does not stop a crafted ID from reading another tenant's data.
• List exact [frontend_origins] rather than wildcards, since permissive CORS undermines the rest of the auth setup.
• Keep the test-per-rule step; assert the denied path, not just the allowed one, because missing negative tests hide broken rules.
• Iterate by asking for a @PreAuthorize expression for one tricky permission and its matching allow/deny tests.