Ory - Hardened OAuth 2.0, OpenID Connect and Identity Server

What is Ory

Ory is an open-source identity stack. This image runs two of its servers, wired together so they behave as one product. Ory Hydra is an OpenID Certified OAuth 2.0 and OpenID Connect provider: it issues access, refresh and ID tokens for your applications, supports the authorization code, client credentials, refresh, device and token-exchange flows, and publishes a standard discovery document and JWKS. Hydra holds no user accounts of its own by design. Ory Kratos supplies them - registration, login, account settings, second factors and sessions, all API-first. The included Ory reference user interface renders the login, registration, settings and consent screens for both, so an application points at one discovery URL and is done.

Why self-host Ory

An identity server sees every login and every user attribute you hold, and the tokens it signs are the keys to everything behind them. Self-hosting keeps that data in your own subscription and region, so GDPR residency and retention become a configuration choice, and cost scales with the VM rather than per monthly active user.

What this VM image adds

Security hardening:

• No credentials in the image - both database passwords, the token-signing and cookie secrets and the encryption key are generated on your instance at first launch, into /root/ory-credentials.txt (0600)
• Both administrative APIs stay on loopback - Ory ships them without authentication by design, so they are bound to 127.0.0.1, blocked in the firewall and never exposed by the web perimeter
• Self-registration closes itself - the instance accepts the first account you create and then shuts public sign-up, so nobody else can claim it
• Schema migrations run before the services start - both databases are migrated at first launch, not on demand
• TLS perimeter - nginx terminates HTTPS on 443 with a per-instance certificate generated at first launch; Certbot is pre-installed for a CA-signed one
• Bundled PostgreSQL 17 on loopback only - a separate database and role per service, scram-sha-256, no trust rule
• Login and consent screens cannot be framed - X-Frame-Options DENY
• Usage reporting switched off in both services - nothing leaves the instance
• CVE scan - every image is scanned with Trivy before release
• UFW firewall - only 22, 80 and 443 are open; every Ory port and PostgreSQL are blocked

OS hardening (CIS Level 1):

• CIS Level 1 hardened - CIS Ubuntu 24.04 LTS Level 1 Benchmark via ansible-lockdown
• SSH hardening - PasswordAuthentication disabled, key-only access
• Azure IMDS egress - pre-configured (169.254.169.254, 168.63.129.16)

Compliance artifacts (inside the VM):

• SBOM - CycloneDX 1.6 at /etc/lynxroute/sbom.json
• CIS Conformance Report - OpenSCAP HTML at /etc/lynxroute/cis-report.html
• Tailored CIS profile - /usr/share/doc/lynxroute/CIS_TAILORED_PROFILE.md
• Licences - /usr/share/doc/lynxroute/LICENSES.txt

Quick Start

1. Deploy the VM (Standard_D2s_v3 or larger recommended)
2. SSH: ssh -i key.pem <username>@<PUBLIC_IP> (username set during VM creation, default: azureuser)
3. Open https://<PUBLIC_IP>/registration and create the first account - it is yours, and public sign-up closes automatically once it exists
4. Register an application with sudo hydra create client --endpoint http://127.0.0.1:4445 (the full command with your redirect URI is in /root/ory-credentials.txt)
5. Point your application at https://<PUBLIC_IP>/.well-known/openid-configuration

Before you go live

1. Restrict port 443 to the networks that need it until you have created that first account.
2. Move onto your own hostname with sudo ory-set-domain idp.example.com, before registering applications: the hostname is the OpenID Connect issuer and is embedded in every token. The same command enables passkeys, which need a domain rather than an IP.
3. On by default: passwords, authenticator-app two-factor and single-use recovery codes. Email codes, recovery and verification need your own SMTP server; social sign-in needs your own provider credentials.

Accounts, applications, tokens and sessions live in the bundled database and survive reboots.