Sign-in on your own domain
An OAuth 2.0 identity server you run yourself: one Go binary, one PostgreSQL database, and an admin panel for your users, their schema and your client.
A Go program built on the Iris web framework. It creates its tables on first start and needs no other service to sign users in.
PostgreSQL holds users, groups, clients and usage. Dragonfly or Redis is optional and only caches responses.
Tokens, keys and the CORS allowlist live where you run it. The allowlist is edited at runtime from the panel.
Access tokens are JWTs signed with Ed25519. Publish the keys at /.well-known/jwks.json and every service verifies on its own, or asks the server.
A single-use code, a state check, and a redirect URI pinned on the server. The client secret is required at the token step.
For terminals and TVs. The server ships its own consent screen and remembers the decision in a cookie.
For first-party apps that hold the credentials themselves.
Per-client lifetimes. Bump a client's version and every token it ever issued is invalid.
// Ask the server whether a token is still good.
const res = await fetch('https://id.example.com/oauth2/token/introspect', {
method: 'POST',
headers: { 'Content-Type': 'application/json', 'X-Token': serverToken },
body: JSON.stringify({ access_token: token }),
});
const claims = await res.json(); // { username, exp, client_id, ... }POST /oauth2/token/introspect returns the token’s claims.
Mint a token with extra claims for a session that needs them.
Code, access and refresh ages set on the client.
Bump the client version; older tokens stop verifying.
Custom attributes are declared in the server's config with a type each. Mark a field required, or indexed for fast filtering. The panel and the API follow the schema from then on.
Never in the clear, not even inside TLS. The SDKs encrypt each password with AES-GCM under a key you share with the server, so a recorded exchange stays sealed against a quantum computer that breaks the TLS key exchange. At rest, a bcrypt hash.
Sign up one user or import a thousand. List with filters and pages. Soft delete, restore, and reset passwords, one at a time or in bulk.
A group is a saved filter over columns and attributes, nested paths included. Membership is computed when you ask for it, never stored.
Dashboard, users, groups, attributes, cache, CORS, the OAuth2 client, a request log, SDK snippets and billing. It runs in your browser against your server and keeps its token locally.
Screens below are shown with sample data.
The three things an operator touches after the first deploy, each with its own page in the panel.
Reads are cached in Dragonfly or Redis and writes invalidate the routes they touch. The panel shows the entry count and can flush.
Origin patterns are stored in the database and reloaded on save. Add a front end without restarting the server.
Every request records its seconds, megabytes and CPU per client. The billing endpoint totals them.
The Go SDK is the Iris auth SDK, shipped with the server. The C# SDK is Hellenic.Identity.SDK on NuGet, open source, with an ASP.NET Core authentication handler. Both sign users in, verify tokens against your JWKS, encrypt passwords, and manage users.
// The Iris auth SDK fetches /.well-known/jwks.json
// once and verifies every token locally.
sdk, err := identity.New[User](identity.Options{
BaseURL: "https://id.example.com",
Token: serverToken,
})
claims, err := sdk.TokenIntrospect[Claims](ctx, accessToken)// dotnet add package Hellenic.Identity.SDK
var signin = await client.UserSigninAsync(
"user@example.com", "password");
var valid = await client.VerifyTokenAsync(
signin.AccessToken); // local, against the JWKS
var claims = await client
.TokenIntrospectAsync<Dictionary<string, object>>(
signin.AccessToken);From an empty server to a verified token in your own code.
Write a config.yml, or let the wizard at id.hellenic.dev generate one with keys. Start the binary; it prints the server token and the encryption key.
Enter your server URL and the token. The panel talks to your server directly from your browser and stores nothing anywhere else.
Add the Go or C# SDK to your apps, point it at your server, and verify tokens against your JWKS on every request.
The panel at id.hellenic.dev connects to the server you run. Setting one up? The wizard there writes your config.yml, keys included.
Hellenic Identity is a self-hosted OAuth 2.0 identity server built by Hellenic Development. It runs as one Go binary against one PostgreSQL database, on a domain you control, and it ships an admin panel for the users, their schema and the OAuth2 client. Users are described once in the server's config with typed custom attributes, groups are saved filters over those attributes, and access tokens are JWTs signed with Ed25519 that any service can verify against the server's public JWKS. It is built for organisations that cannot send identity data to a vendor's cloud. The Go SDK ships with the Iris web framework, and the C# SDK is on NuGet as Hellenic.Identity.SDK.
Hellenic Identity supports 4 OAuth 2.0 grants: authorization code, device code with a built-in consent screen, password, and refresh token. Access tokens are JWTs signed with Ed25519 by default, and refresh tokens can be encrypted with AES-GCM on top. Lifetimes are set per client for the code, the access token and the refresh token. Bumping a client's version invalidates every token it ever issued, which is how mass revocation works: no list of revoked tokens to keep, one number to change.
Applications verify a Hellenic Identity token in one of two ways. The first is local: fetch the server's public keys once from /.well-known/jwks.json and check the Ed25519 signature on every request without another round trip, which is what the Go and C# SDKs do at startup. The second is to ask the server: POST the token to /oauth2/token/introspect and read back its claims, such as the username, the client id and the expiry. The server can also mint a token with extra claims for a session that needs them, which the panel and the SDKs call enrichment.
Hellenic Identity does not support OpenID Connect in this version. It is an OAuth 2.0 server with a JWKS endpoint, token introspection and token enrichment. The OpenID Connect layer exists in the source but is not switched on, so there is no userinfo endpoint and no ID token yet. An application that needs sign-in, a verified access token and the user's attributes gets those from the OAuth 2.0 endpoints and the user API today, and the same protocol code keeps working when the layer is enabled.
Hellenic Identity needs one Go binary and one PostgreSQL database. The binary is built on the Iris web framework, creates its tables on first start, and prints the server token and the encryption key that the admin panel asks for. Dragonfly or Redis is optional and only used for response caching, which the panel can switch off. There is no Docker image and no hosted edition: you run it on your own server, on your own domain, and the panel at id.hellenic.dev talks to it from your browser and stores nothing anywhere else.