Разверните его. Подключите свой продукт. Эксплуатируйте его безопасно.

Для кого это

В этом справочнике есть два независимых направления. Операторы могут завершить развертывание, не будучи разработчиками приложений. Команды разработчиков могут начать работу с уровня разработчиков, как только появится работоспособный поставщик 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

При проверке прослушивателя обратной связи вручную в режиме доверенного прокси отправьте адрес локального перенаправленного клиента:

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

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

4. Работайте на своем языке

5. Защитите API

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

6. Сервис-за-сервис

Используйте service клиент с client_credentials. Он получает только токен доступа — без человеческого сеанса и без токена обновления.

Контрольный список производства

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

Ссылка