openauth-core

Core types and primitives for OpenAuth-RS.

Status

This package is in experimental beta. Contracts for adapters, plugins, options, and HTTP routing may change before stable release.

The current core is usable for prototypes and controlled server-side flows such as email/password auth, OAuth social sign-in, sessions, cookies, verification tokens, rate limiting, and SQL/Redis-backed storage paths. It is not yet a drop-in production-grade replacement for the full Better Auth ecosystem: larger plugins, some adapter coverage, and final OpenAPI/error contract hardening are still in progress.

What It Provides

openauth-core contains the shared server contracts used by the rest of the workspace: API requests and responses, auth context, cookies, crypto helpers, database adapter traits, schemas, errors, options, plugins, sessions, users, verification storage, and rate limiting.

Feature Flags

Default features preserve the current compatibility surface:

jose: enables JOSE/JWE helpers backed by josekit, including encrypted cookie cache and account-cookie JWE support.
oauth: enables OAuth/social route support and the openauth_core::oauth re-export.
social-providers: enables the openauth_core::social_providers re-export.

Use openauth-core --no-default-features for a minimal core build. That path keeps HS256 JWT, password hashing, secret rotation, signed cookies, sessions, email verification, and compact/JWT cookie cache available without compiling josekit or OpenSSL. JWE-only paths fail closed with a typed OpenAuthError::FeatureDisabled { feature: "jose" } error until jose is enabled.

Example

use openauth_core::db::{auth_schema, AuthSchemaOptions};

let schema = auth_schema(AuthSchemaOptions::default());
let user_table = schema.table_name("user")?;

Application code usually depends on openauth; adapter, plugin, and integration crates use openauth-core for stable internal contracts.

Production Notes

Configure a strong secret and explicit base_url in deployed environments.
Use a persistent adapter such as SQLx/Postgres or SQLx/MySQL for primary auth data; MemoryAdapter is for tests and local development.
Use a real distributed rate-limit store for multi-instance deployments.
Sensitive routes bypass the signed cookie cache and read the backing session store directly, but deployments should still use HTTPS-only cookies and trusted origins.
Secondary storage is supported for sessions and verification tokens when a SecondaryStorage implementation is configured.