Identity (sinauth)

sinauth is the dedicated OAuth 2.0 / OpenID Connect authorization server for the opensecstack ecosystem. It acts as the single identity plane for all SIN platforms — one account grants access to every platform via single sign-on. What Auth0 is globally, sinauth is for SIN.

sinauth is written in pure Go with no runtime dependencies beyond PostgreSQL. It runs on port 8100 in the default Docker Compose topology. Licence: Apache 2.0.

What is sinauth?

Each SIN platform is registered as an OAuth 2.0 client. When a user logs in to any platform, their browser is redirected to sinauth, they authenticate once, and receive RS256-signed ID and access tokens. Subsequent logins to other platforms within the same SSO session skip the login form entirely.

• Issues RS256-signed ID tokens and access tokens
• Standards: OAuth 2.0 + OpenID Connect Core 1.0
• Authorization code + PKCE (S256) — PKCE is mandatory for every client
• Refresh tokens with configurable TTL (default 30 days)
• TOTP multi-factor authentication (authenticator apps)
• Social login: Google, GitHub
• Admin dashboard for managing OAuth clients (platforms)

OIDC endpoints

The production issuer is https://auth.sin.to. For local development the server listens at http://localhost:8100.

Issuer:              https://auth.sin.to
Authorization:       https://auth.sin.to/oauth/authorize
Token:               https://auth.sin.to/oauth/token
UserInfo:            https://auth.sin.to/oauth/userinfo
JWKS:                https://auth.sin.to/.well-known/jwks.json
End session:         https://auth.sin.to/oauth/endsession
Revocation:          https://auth.sin.to/oauth/token/revoke
Introspection:       https://auth.sin.to/oauth/token/introspect
Discovery document:  https://auth.sin.to/.well-known/openid-configuration

Scopes:              openid profile email offline_access
Grant type:          authorization_code + PKCE (S256)
ID token signing:    RS256

The discovery document at /.well-known/openid-configuration is the authoritative source for all endpoint URLs. Clients should read it once at startup and cache for one hour (Cache-Control: public, max-age=3600).

Authorization code + PKCE flow

PKCE (Proof Key for Code Exchange) is mandatory for every registered client. The method is always S256 — the code challenge is BASE64URL(SHA-256(code_verifier)).

1. The client generates a random code_verifier and computes the code_challenge.
2. The browser is redirected to /oauth/authorize with the challenge.
3. sinauth validates the client and redirect URI, checks the SSO session cookie, and presents the login form if needed.
4. After authentication (and consent on first visit), sinauth redirects back with a short-lived authorization code (5-minute TTL, single-use).
5. The client exchanges the code for tokens at /oauth/token, providing the code_verifier. sinauth verifies SHA-256(verifier) == challenge.
6. sinauth issues an RS256 access token (1-hour TTL), an RS256 ID token (5-minute TTL), and an opaque refresh token (30-day TTL, stored as a SHA-256 hash).

Token format

Both access tokens and ID tokens are standard JWTs signed with RS256. The JWT header includes a kid field so verifying parties can select the correct public key from the JWKS response.

Platforms verify tokens by fetching https://auth.sin.to/.well-known/jwks.json, reading the kid from the JWT header, selecting the matching JWK, and verifying the RS256 signature. They also check exp, iss(https://auth.sin.to), and aud (their own client_id).

MFA and social login

sinauth supports TOTP multi-factor authentication enforced centrally — users register an authenticator app and every login requires the current TOTP code. Social login via Google and GitHub is supported alongside password-based accounts. MFA state is transparent to the platforms; they receive normal RS256 tokens regardless of which authentication method was used.

Organizations

sinauth recognizes two kinds of identity subject: an individual user, and — as of v1.1 — an organization. Organizations model government institutions, private companies, e-commerce businesses, and NGOs as first-class identities alongside the people who act on their behalf.

A user can belong to one or more organizations as a member (with a role of owner, admin, or member). Membership doesn't change how a user signs in — the individual login flow above is untouched — but it unlocks the option to act on behalf of an organization for a given session. When authorizing, a client can pass an organization_id; if the user is a member, the resulting ID token and access token carry org_id, org_role, and org_type claims alongside the usual sub. Omit it, and tokens are issued exactly as they always were — this is additive, not a breaking change, so platforms that don't care about organizations can ignore the claims entirely.

If a user belongs to more than one organization and doesn't specify which one, sinauth shows an organization picker step instead of guessing — the same way a consent screen appears on first login to a new platform. A single token never represents both an individual and an organization at once.

SDK clients

The opensecstack SDK & Contracts ships sinauth client helpers in Go and TypeScript. These implement the OIDC discovery fetch, JWKS caching, and RS256 token verification so platform teams do not need to re-implement them.

Platform integration

Each SIN platform has a dedicated integration guide under sinauth/docs/integration/. The guides cover client registration, redirect URI configuration, scope selection, and token verification for:APIGuard, IRFlow, NIS2 Compass, ThreatFlow, OpenCSIRT, CyberPath, SecureLab,OpenScrub, VertGuard, and the SIN Community platform.