Why jSentinel?
A framework-neutral, evidence-driven security library for the JVM — small enough to read, strict enough to trust. Authentication, authorization, audit, brute-force, sessions, multi-tenancy, method security and a Policy API behind one annotation set for plain Java, REST and Vaadin — no Spring or Jakarta required, nothing extra to deploy.
Framework-Neutral Core
jSentinel-core has zero Vaadin / Servlet / REST-framework dependencies. Three thin adapters map one decision model to navigation or HTTP status.
One Annotation Set, Three Adapters
The same @RequiresRole / @RequiresPermission protect Vaadin views, REST handlers and plain Java services. Learn it once.
A Library, Not a Server
Runs in your process — nothing extra to deploy, patch or operate. No central service to keep alive.
Evidence, Not Claims
Mutation-tested (87–97 % on the mature modules) — tests proven to catch real bugs, not just execute lines.
Standards-Mapped + SBOM
OWASP ASVS V2, NIST SP 800-63B and a 40-CWE matrix — plus a CycloneDX SBOM and reproducible builds for review.
🇪🇺 Made in the EU · EUPL 1.2
Independent maintenance, no third-party CDNs, no lock-in. The core stays EUPL 1.2 forever.
How it compares
An honest look at fit — not a scoreboard. Spring Security and Keycloak are mature projects with full OIDC/OAuth2 today, areas where jSentinel is still on the roadmap.
| Dimension | jSentinel for Java | Spring Security | Keycloak / IdP | Hand-rolled |
|---|---|---|---|---|
| Runs as | library, in-process | library (Spring) | separate server you operate | your code |
| Framework coupling | none (no Spring/Jakarta) | Spring | protocol-coupled | none |
| Plain Java / REST / Vaadin | ✓ one annotation set | Spring-centric | via tokens | DIY |
| Footprint | small; zero 3rd-party in core | large | service + infra | minimal, you own it |
| Authn / Authz | pluggable SPI + Policy API | extensive | IdP-managed | DIY |
| Audit · brute-force · session · tenancy | built-in SPIs | partial / add-ons | partly (IdP side) | DIY |
| Method security | @Secured + runtime proxy | @PreAuthorize (AOP) | n/a | DIY |
| Persistence | store-agnostic SPIs + Eclipse Store ref | your stack | its own DB | DIY |
| Test rigor | mutation-tested 87–97 % | mature | mature | varies |
| Standards mapping | published ASVS / NIST / 40-CWE | — | protocol standards | — |
| Supply chain | CycloneDX SBOM, reproducible | — | — | — |
| OIDC / OAuth2 / SAML today | roadmap 00.76–00.79 | ✓ | ✓ (core strength) | DIY |
| License | EUPL 1.2 | Apache 2.0 | Apache 2.0 | yours |
| Operate a server? | no | no | yes | no |
Is it the right fit?
✓ A great fit when
- You’re on Vaadin, a JDK REST server, or plain Java and don’t want Spring just for security.
- You want one consistent security model across UI, API and background services.
- You value small, auditable, evidence-backed dependencies (mutation tests, SBOM, standards mapping).
- You want no extra server to run — security lives in your app.
- EU-made / EUPL and supply-chain transparency matter to you.
Look elsewhere (for now) when
- You need full OIDC / OAuth2 / SAML today — use Keycloak or Spring Security; jSentinel’s identity stack is planned for 00.76–00.79.
- Your stack is deeply Spring and Spring Security already fits.
- You need a central IdP / SSO server for many apps — pair an IdP with jSentinel on the app side.