HomeHellenic Identity
Live

Hellenic Identity

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.

One binary

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.

One database

PostgreSQL holds users, groups, clients and usage. Dragonfly or Redis is optional and only caches responses.

Your domain

Tokens, keys and the CORS allowlist live where you run it. The allowlist is edited at runtime from the panel.

4 grants, one key set

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.

Authorization code

A single-use code, a state check, and a redirect URI pinned on the server. The client secret is required at the token step.

Device code

For terminals and TVs. The server ships its own consent screen and remembers the decision in a cookie.

Password

For first-party apps that hold the credentials themselves.

Refresh token

Per-client lifetimes. Bump a client's version and every token it ever issued is invalid.

verify.js
// 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, ... }

Introspection

POST /oauth2/token/introspect returns the token’s claims.

Enrichment

Mint a token with extra claims for a session that needs them.

Lifetimes per client

Code, access and refresh ages set on the client.

Mass revocation

Bump the client version; older tokens stop verifying.

Describe your users once

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.

  • text
  • number
  • email
  • date
  • phone
  • bool
  • slice
  • map
  • uuid

Passwords

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.

Lifecycle

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.

Groups are filters

A group is a saved filter over columns and attributes, nested paths included. Membership is computed when you ask for it, never stored.

  • =
  • IS
  • IS NOT
  • ILIKE
  • @>
  • #>>
  • <
  • >
  • <=
  • >=
  • AND
  • OR

Everything from one panel

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 dashboard of the admin panel: user and group counts, cache entries, quick actions and the server's JWKS endpoint.
The Users page of the admin panel: a list of user records with their custom attributes, a search box and bulk actions.
Users, with every custom attribute the schema defines
The Attributes page of the admin panel: the user schema field by field, with type, required and indexed flags.
The user schema, field by field
The Groups page of the admin panel: filter-based user groups with their terms.
Groups are filters, not lists

Cache, CORS, and the bill

The three things an operator touches after the first deploy, each with its own page in the panel.

Response caching

Reads are cached in Dragonfly or Redis and writes invalidate the routes they touch. The panel shows the entry count and can flush.

CORS at runtime

Origin patterns are stored in the database and reloaded on save. Add a front end without restarting the server.

Metering

Every request records its seconds, megabytes and CPU per client. The billing endpoint totals them.

Go and C#, the same 16 calls

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.

main.go
// 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)
Program.cs
// 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);

Three steps

From an empty server to a verified token in your own code.

1

Run the server

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.

2

Open the panel

Enter your server URL and the token. The panel talks to your server directly from your browser and stores nothing anywhere else.

3

Integrate

Add the Go or C# SDK to your apps, point it at your server, and verify tokens against your JWKS on every request.

Run sign-in on your own domain

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: common questions

What is Hellenic Identity?

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.

Which OAuth 2.0 grants does Hellenic Identity support?

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.

How do applications verify a Hellenic Identity token?

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.

Does Hellenic Identity support OpenID Connect?

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.

What does Hellenic Identity need to run?

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.