Розгорніть його. Підключіть свій продукт. Керуйте ним безпечно.

Для кого це

Цей підручник має дві незалежні частини. Оператори можуть завершити розгортання, не будучи розробниками програм. Команди продуктів можуть почати роботу з розробниками, коли з’явиться здоровий емітент OpenProof.

Частина I — Розгортання та налаштування

1. Встановіть перевірене попередньо зібране середовище виконання

curl -fsSL https://genyleap.com/install/openproof | sudo sh

Програма встановлення виявляє підтримувану архітектуру Ubuntu/Debian і ЦП, вирішує випуск, завантажує відповідний попередньо зібраний пакет і перевіряє його маніфест SHA-256. Він не встановлює компілятор або мовчки повертається до збірки вихідного коду.

2. Виберіть джерело ідентифікації

Використовуйте стабільне загальнодоступне ім’я хоста, наприклад auth.example.com. Це стає емітентом OIDC і основою для зворотних викликів постачальника.

issuer:   https://auth.example.com
callback: https://auth.example.com/auth/federated/callback
discovery:https://auth.example.com/.well-known/openid-configuration
jwks:     https://auth.example.com/.well-known/jwks.json

3. PostgreSQL і секрети

Виберіть локальний PostgreSQL для компактного розгортання на одному хості або надайте наявний postgres:// / postgresql:// URL. OpenProof застосовує міграції контрольної суми перед відкриттям приймача. Інсталятор генерує спеціальні секрети підпису, шифрування, перцю, аудиту, показників і доставки з обмеженими дозволами.

4. Налаштуйте доставку підтвердження

sudo openproof config delivery

5. Налаштуйте постачальників послуг входу

Вибирайте лише постачальників, справжні облікові дані яких готові. Google, GitHub, Microsoft, Apple, LinkedIn, Telegram, X, Ethereum і Farcaster можна налаштувати пізніше без перевстановлення OpenProof.

sudo openproof config providers

Поширені заповнювачі, такі як 0, test, dummy, example і placeholder розглядаються як відкладена конфігурація, а не справжні облікові дані постачальника.

6. Налаштуйте захищену програму вгору

OpenProof gateway
    ↓
127.0.0.1:3000
    ↓
your product backend

Сервер продукту не повинен працювати, щоб власна площина ідентифікації/OAuth OpenProof стала справною. Змініть налаштування шлюзу/вихідного каналу за допомогою sudo openproof config main.

7. TLS і вхід

Використовуйте Let's Encrypt для справжнього загальнодоступного імені DNS, надайте наявний сертифікат або припиніть TLS на власному вході/балансувальнику навантаження. Зарезервовані назви, такі як *.example.com, *.test і *.invalid за умовчанням використовується зовнішній/відкладений TLS, а не приречений запит загальнодоступного сертифіката.

8. Перевірте стан здоров'я

sudo openproof status
openproof status --full
sudo openproof doctor

Під час ручного тестування loopback-прослухувача в режимі довіреного проксі надішліть локальну перенаправлену адресу клієнта:

curl -fsS \
  -H 'X-Forwarded-For: 127.0.0.1' \
  http://127.0.0.1:18443/health/ready

{"status":"ok"}

Частина II — Створення за допомогою OpenProof

Інтеграція продукту використовує OAuth 2.0/OpenID Connect. Програми отримують маркери OAuth/OIDC; вони не копіюють файли cookie сесії браузера OpenProof у свій власний домен.

User
  ↓
your app
  ↓ redirect
OpenProof /oauth/authorize
  ↓ authenticate
your callback ?code=...&state=...&iss=...
  ↓ code + PKCE verifier
OpenProof /oauth/token
  ↓
access_token + id_token + optional refresh_token

1. Реєстрація заявки та клієнта

Активний власник IAL2 може використовувати /admin/console або API адміністрування. Виберіть тип клієнта, який відповідає вашому продукту.

2. Використовуйте код авторизації + PKCE

Створіть високоентропійний верифікатор, виклик PKCE S256, випадковий state і випадковий nonce. Під час зворотного виклику перевірте стан і повернутого емітента перед обміном кодом.

curl --fail-with-body https://auth.example.com/oauth/token \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'grant_type=authorization_code' \
  --data-urlencode 'client_id=CLIENT_ID' \
  --data-urlencode 'code=AUTHORIZATION_CODE' \
  --data-urlencode 'redirect_uri=https://app.example.com/oauth/callback' \
  --data-urlencode 'code_verifier=PKCE_VERIFIER'

3. Перевірте токени OIDC

Не просто декодуйте маркер ID. Перевірте RS256 проти JWKS емітента та перевірте iss, aud, exp, iat і оригінал nonce; також честь nbf, azp і at_hash де присутні.

4. Працюйте своєю мовою

5. Захист API

Зареєструйте ресурс із аудиторією та областями, а потім або перевірте/перевірте маркери доступу у вашій серверній частині, або розмістіть маршрути за шлюзом OpenProof. Тримайте авторизацію продукту вужчою, ніж «токен дійсний»: перевірте аудиторію, обсяг і свою бізнес-політику.

6. Сервіс-сервіс

Використовуйте a service клієнт с client_credentials. Він отримує лише маркер доступу — ні сеансу користувача, ні маркера оновлення.

Контрольний лист виробництва

• Справжній DNS і надійний HTTPS на місці.
• Існують резервні копії PostgreSQL, і метод відновлення був протестований.
• Для доставки підтвердження використовується справжній ретранслятор/вебхук SMTP, а не зразки імен хостів.
• Початковий власник захищений MFA/TOTP.
• Зворотні виклики постачальника точно збігаються з джерелом ідентифікатора виробництва.
• URI перенаправлення OAuth є точними, а перевірку PKCE/state/nonce увімкнено.
• Ідентифікаційні маркери перевіряються підписом/претензією; маркери доступу авторизовані аудиторією та сферою дії.
• Ротація маркерів оновлення зберігається атомарно.
• Готовність стежать і openproof doctor проходить після зміни інфраструктури.
• Секрети постачальника/клієнта/бази даних/підпису ніколи не потрапляють у систему керування джерелами, журнали чи підказки ШІ.

довідка