Module server 

Available on crate features sso-server and sso only.

AuthServer — a minimal OAuth 2.0 Authorization Server / token issuer.

Lets rws be the identity provider for downstream services or single-page apps, rather than always delegating to an external OIDC provider (that’s super::oidc_auth::OidcAuth’s job — this is the reverse role).

Usage

use std::sync::Arc;
use std::time::Duration;
use rust_web_server::app::App;
use rust_web_server::core::New;
use rust_web_server::session::SessionStore;
use rust_web_server::sso::server::{AuthServer, AuthServerConfig};
use rust_web_server::sso::client_store::{ClientStore, OAuthClient, GrantType};

let auth_server = AuthServer::new(AuthServerConfig {
    issuer:            "https://myapp.com".into(),
    signing_secret:    std::env::var("RWS_AUTH_SIGNING_SECRET").unwrap(),
    access_token_ttl:  Duration::from_secs(3600),
    refresh_token_ttl: Duration::from_secs(86_400 * 30),
    clients: ClientStore::new().add(OAuthClient {
        client_id:     "backend-service".into(),
        client_secret: Some("s3cr3t".into()),
        redirect_uris: vec![],
        grants:        vec![GrantType::ClientCredentials],
        scopes:        vec!["api:read".into()],
    }),
    sessions: Arc::new(SessionStore::new(86_400)),
});

let app = App::new().wrap(auth_server);
// Registers, and intercepts: POST /oauth/token, GET /oauth/authorize,
// GET /.well-known/openid-configuration, GET /.well-known/jwks.json

Deviations from a full OAuth 2.0 Authorization Server

• HS256, not RSA/EC. Tokens are signed with the existing crate::auth::build_jwt/crate::auth::verify_jwt HS256 machinery (auth feature) rather than an RSA/EC private key loaded from PEM. This crate has no PEM/DER private-key parser; adding one — plus the signing-side counterpart to super::jwks::JwksCache’s verification-only RSA/ES code — would be a large addition for a feature that already has a fully adequate, already-tested symmetric alternative when the issuer and every resource server share one secret (the common case for “rws issues its own tokens”). Consequently GET /.well-known/jwks.json always returns an empty key set — there is no public key to publish for a symmetric algorithm. Resource servers must be configured with the same signing_secret directly (e.g. auth::JwtLayer or auth::verify_jwt).
• /oauth/authorize trusts an existing application session, not a built-in login page. The spec for this feature says “redirect to login page or IdP, then back with code” but building a username/ password login form is out of scope (the same boundary super::oidc_auth::OidcAuth draws around needing an external IdP to already exist). AuthServer instead checks the browser’s session (via the existing crate::session::SessionStore) for a configurable key (default "user_id", override with AuthServer::subject_session_key) — if present, that value becomes the issued token’s sub claim and a code is minted immediately; if absent, the browser is redirected to a configurable login_url (default /login, override with AuthServer::login_url) with ?return_to=<original authorize URL>. Populating that session is the embedding application’s own responsibility.
• No ClientStore::from_env()/::from_db(). Client secrets belong in code or a real secret store, not flat env vars — and unlike super::config::OidcConfig (one client per process), a ClientStore is a list of clients with no natural flat-env-var encoding. The builder (ClientStore::new().add(...)) already covers registering clients from wherever the caller wants to load them.

Structs

AuthServer

A minimal OAuth 2.0 Authorization Server — see the module docs.

AuthServerConfig

Configuration for AuthServer.