This is currently pre-release beta software. I don’t recommend using it in
production at the moment. It has not yet undergone any sort of official
security review, and I am not a security expert. The plan is to arrange for a
security review before reaching 1.0.

That said, testing and feedback (especially with respect to security) would be
greatly appreciated.

obligator is a relatively simple and opinionated OpenID Connect (OIDC) Provider
(OP) server designed for self-hosters.

There are lots of great open source OIDC servers out there (see
comparison). I made obligator because I
needed a specific combination of features I didn’t find in any of the others.
Here’s a brief list. See the feature explanation
section for more detailed information.

• Simple to deploy and manage. Static executable and either flat-file or sqlite
  storage
• Support for anonymous OAuth2 clients
• Authenticate to multiple domains at once
• Passwordless email login
• Configurable at runtime with an API
• Support for forward auth
• Support for trusted headers
• Support for upstream social login providers (GitLab, GitHub, Google, etc)

The overarching philosophy of obligator is that identities are built on email.
Email isn’t perfect, but it’s the globally unique federated identity we have
that works today.

Thus the purpose of obligator is to validate that a user controls an email
address as simply as possible, and communicate that to the application the
user is attempting to log in to. Validation can either be done directly
through SMTP, or delegated to upstream OIDC (and some plain OAuth2) providers.

Here’s a fairly complete JSON storage file (obligator_storage.json). Note
that I call it “storage” and not “config” because it’s not static, and more
like a simple database. obligator will update it at runtime if new values are
provided through the API.

{
  "root_uri": "https://example.com",
  "login_key_name": "obligator_login_key",
  "oauth2_providers": [
    {
      "id": "google",
      "name": "Google",
      "uri": "https://accounts.google.com",
      "client_id": "",
      "client_secret": "",
      "openid_connect": true
    },
    {
      "id": "lastlogin",
      "name": "LastLogin.io",
      "uri": "https://lastlogin.io",
      "client_id": "https://example.com",
      "client_secret": "",
      "openid_connect": true
    }
  ],
  "smtp": {
    "server": "smtp.fastmail.com",
    "username": "",
    "password": "",
    "port": 587,
    "sender": "auth@example.com",
    "sender_name": "Example"
  },
  "jwks": "",
  "users": [
    {
      "email": "user1@example.com"
    },
    {
      "email": "user2@example.com"
    }
  ],
  "public": false
}

If you’re already using docker, it’s the easiest way to get started with
obligator:

mkdir obligator_docker/
cp obligator_storage.json obligator_docker/

docker run --user $(id -u):$(id -g) --rm -it -v $PWD/obligator_docker:/data -v $PWD/obligator_docker:/api -p 1616:1616 anderspitman/obligator:latest -storage-dir /data -api-socket-dir /api -root-uri example.com -port 1616

You can also download static executables for various platforms from the
releases page.

Currently the API is only offered through unix sockets. This reduces the
chance that it accidentally gets exposed, which is important because
it’s not authenticated in any way.

There’s not any documentation, and the API is in flux, so refer to the
source code for usage.

Here’s an example assuming you ran the docker command above:

curl --unix obligator_docker/obligator_api.sock dummy-domain/oauth2