Yerləşdirin. Məhsulunuzu qoşun. Təhlükəsiz işlədin.

Bu bələdçi kimlər üçündür

Bu bələdçinin iki müstəqil xətti var. Operatorlar tətbiq tərtibatçısı olmadan deployment xəttini tamamlaya bilər. Məhsul komandaları sağlam OpenProof issuer mövcud olduqda developer xəttindən başlaya bilər.

Bölmə I — Yerləşdirmə və konfiqurasiya

1. Təsdiqlənmiş hazır runtime-ı quraşdırın

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

Production installer dəstəklənən Ubuntu/Debian və CPU arxitekturasını müəyyən edir, release-i seçir, uyğun hazır bundle-ı endirir və SHA-256 manifestini yoxlayır. Compiler quraşdırmır və səssiz şəkildə source build-ə keçmir.

2. Identity origin seçin

Belə stabil açıq hostname istifadə edin: auth.example.com. Bu, OIDC issuer və provider callback-ləri üçün əsas olur.

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 və secret-lər

Kompakt single-host deployment üçün lokal PostgreSQL seçin və ya mövcud postgres:// / postgresql:// URL verin. OpenProof listener-i açmazdan əvvəl checksum-lu migration-ları tətbiq edir. Installer məhdud icazələrlə signing, encryption, pepper, audit, metrics və delivery secret-ləri yaradır.

4. Verification delivery-ni konfiqurasiya edin

sudo openproof config delivery

5. Giriş provider-lərini konfiqurasiya edin

Yalnız real credential-ları hazır olan provider-ləri seçin. Google, GitHub, Microsoft, Apple, LinkedIn, Telegram, X, Ethereum və Farcaster sonradan OpenProof-u yenidən quraşdırmadan konfiqurasiya oluna bilər.

sudo openproof config providers

Belə geniş yayılmış placeholder-lar 0, test, dummy, example and placeholder real provider credential-ları əvəzinə deferred configuration kimi qəbul edilir.

6. Qorunan application upstream-i konfiqurasiya edin

OpenProof gateway
    ↓
127.0.0.1:3000
    ↓
your product backend

OpenProof-un öz identity/OAuth plane-inin sağlam olması üçün məhsul backend-i işləməli deyil. Gateway/upstream ayarlarını bununla dəyişin: sudo openproof config main.

7. TLS və ingress

Real açıq DNS adı üçün Let’s Encrypt istifadə edin, mövcud sertifikat verin və ya TLS-i öz ingress/load balancer-də terminate edin. Belə rezerv adlar: *.example.com, *.test and *.invalid uğursuz olacaq public certificate sorğusu əvəzinə default olaraq external/deferred TLS istifadə edir.

8. Sağlamlığı yoxlayın

sudo openproof status
openproof status --full
sudo openproof doctor

Trusted-proxy rejimində loopback listener-i manual yoxlayarkən lokal forwarded client ünvanını göndərin:

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

{"status":"ok"}

Bölmə II — OpenProof ilə inkişaf

Məhsul inteqrasiyası OAuth 2.0/OpenID Connect istifadə edir. Tətbiqlər OAuth/OIDC token-ləri alır; OpenProof brauzer session cookie-sini öz domain-lərinə kopyalamır.

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. Application və client qeyd edin

Aktiv IAL2 owner istifadə edə bilər: /admin/console və ya administration API istifadə edə bilər. Məhsulunuza uyğun client növünü seçin.

2. Authorization Code + PKCE istifadə edin

Yüksək entropy-li verifier, PKCE S256 challenge və təsadüfi state və təsadüfi nonce. yaradın. Callback zamanı code exchange-dən əvvəl state və qaytarılan issuer-i doğrulayın.

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 token-ləri yoxlayın

ID token-i sadəcə decode etməyin. RS256-nı issuer JWKS ilə yoxlayın və iss, aud, exp, iat və ilkin nonce; həmçinin nbf, azp and at_hash mövcud olduqda nəzərə alın.

4. Öz dilinizdə işləyin

5. API-ləri qoruyun

Audience və scope-larla resource qeyd edin; sonra access token-ləri backend-də validate/introspect edin və ya route-ları OpenProof gateway arxasına qoyun. Məhsul authorization-ını “token etibarlıdır” ifadəsindən daha dar saxlayın: audience, scope və biznes policy-ni yoxlayın.

6. Xidmətdən xidmətə

Bir service client ilə client_credentials. Yalnız access token alır — insan sessiyası və refresh token yoxdur.

Production yoxlama siyahısı

• Real DNS və etibarlı HTTPS qurulub.
• PostgreSQL backup-ları var və restore sınağı test edilib.
• Verification delivery nümunə hostname-lər əvəzinə real SMTP relay/webhook istifadə edir.
• İlkin owner MFA/TOTP ilə qorunur.
• Provider callback-ləri production identity origin ilə tam uyğun gəlir.
• OAuth redirect URI-lər dəqiqdir və PKCE/state/nonce validation aktivdir.
• ID token-lər signature/claim üzrə yoxlanır; access token-lər audience və scope ilə authorize olunur.
• Refresh-token rotation atomik şəkildə persist olunur.
• Readiness monitorinq olunur və openproof doctor infrastruktur dəyişikliklərindən sonra uğurla keçir.
• Provider/client/database/signing secret-ləri source control, log və AI prompt-larına heç vaxt daxil olmur.

İstinad