AuthKit-Pro security

Implemented protections

• Spring Security owns password checking, BCrypt, JWT validation, OAuth/OIDC, WebAuthn, One-Time Token authentication, authorization, and CSRF infrastructure.
• Independent session credentials are random, digest-only at rest, rotated under database locking, and revoked by strict family replay handling.
• JWTs require expiry, issuer, audience, an enabled account, and an active session matching sid, uid, and subject.
• Protected account resources are scoped to the principal; account-state administration requires ROLE_ADMIN.
• Registration, verification, and recovery responses avoid account-existence disclosure.
• OAuth linking requires JWT, CSRF, current-password proof, and a session/provider-bound intent; provider emails never auto-link.
• Lifecycle links use URL fragments and explicit confirmation; GET requests never perform the security operation.
• Activity history excludes passwords, credentials, headers, request bodies, email-link tokens, and provider tokens.

Credential and session handling

Refresh and account-lifecycle credentials are digest-only in application storage. Native Spring JDBC One-Time Token values are stored raw by framework design and therefore require restricted database and backup access. Access JWTs remain valid only while their signed session and account state remain active.

CORS, CSRF, and browser login

• The stateless Bearer-only /api/** chain disables CSRF because cookies do not authenticate it.
• WebAuthn, OAuth linking, and One-Time Token browser mutations retain cookie-backed CSRF, even when a Bearer JWT is also supplied.
• Configure exact trusted CORS and WebAuthn origins; production browser flows require HTTPS and secure session cookies.
• OAuth callbacks return JSON token responses and never place AuthKit access or refresh credentials in redirect URLs.

External providers and action links

• Configure provider credentials through standard Spring Boot OAuth2 client properties and keep each registration ID stable.
• Set AUTHKIT_ACCOUNT_ACTION_URL to a complete trusted HTTPS page without credentials, query, or fragment.
• Set AUTHKIT_MAIL_REQUIRED=true and configure tested TLS-enabled Spring Mail transport for production.
• Monitor delivery failures; notifications are best effort after commit without a durable outbox or retry guarantee.

Rate limiting and operations

Deployment infrastructure must apply gateway or reverse-proxy rate limits to login, registration, refresh, verification, recovery, and magic-link generation. Generic responses are not a constant-time guarantee and do not replace anti-abuse controls.

• Use a persistent database with backups and restricted credentials.
• Provide a stable high-entropy JWT secret of at least 32 characters.
• Disable demo data and the API tester.
• Restrict sensitive body, header, callback, access, and ORM bind logging.
• Configure trusted proxy handling and monitor database health.

Explicit security limitations

• MFA, conditional MFA, JWT step-up, and TOTP are not implemented.
• Persistent lockout, distributed rate limiting, credential/device reputation, and distributed sessions are not implemented.
• Refresh replay handling has no grace period; concurrent refresh or retry after a lost response can require sign-in again.
• Mail delivery has no durable retry/outbox guarantee.
• Real passkey ceremonies, provider callbacks, SMTP delivery, and production MySQL behavior require environment-specific verification.

Deployment remains your responsibility

AuthKit-Pro supplies documented authentication infrastructure and explicit boundaries. The buyer remains responsible for reviewing, configuring, testing, deploying, monitoring, backing up, and operating it for the application's requirements.