انشره. اربط منتجك. شغّله بأمان.

لمن هذا الدليل

يحتوي هذا الدليل على مسارين مستقلين. يمكن للمشغلين إكمال مسار النشر دون أن يكونوا مطوري تطبيقات، ويمكن لفرق المنتج بدء مسار التطوير بعد توفر issuer سليم لـ OpenProof.

الجزء الأول — النشر والتهيئة

1. ثبّت runtime الجاهز والمتحقق منه

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

يكتشف مثبّت الإنتاج Ubuntu/Debian ومعمارية CPU المدعومين، ويحدد release، وينزّل bundle جاهزًا مطابقًا ويتحقق من manifest الخاص به عبر SHA-256. لا يثبت compiler ولا يعود بصمت إلى البناء من المصدر.

2. اختر identity origin

استخدم hostname عامًا وثابتًا مثل auth.example.com. سيصبح هذا هو OIDC issuer والأساس لـ callback الخاصة بالمزوّدين.

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 migrations ذات checksums قبل فتح listener. وينشئ المثبّت secrets مخصصة للتوقيع والتشفير وpepper والتدقيق والmetrics والتسليم بصلاحيات مقيّدة.

4. هيّئ تسليم التحقق

sudo openproof config delivery

5. هيّئ مزوّدي تسجيل الدخول

اختر فقط المزوّدين الذين أصبحت بيانات اعتمادهم الحقيقية جاهزة. يمكن إعداد Google وGitHub وMicrosoft وApple وLinkedIn وTelegram وX وEthereum وFarcaster لاحقًا دون إعادة تثبيت OpenProof.

sudo openproof config providers

تُعامل placeholders الشائعة مثل 0, test, dummy, example and placeholder تُعامل كإعداد مؤجل بدل بيانات اعتماد حقيقية للمزوّد.

6. هيّئ upstream للتطبيق المحمي

OpenProof gateway
    ↓
127.0.0.1:3000
    ↓
your product backend

لا يلزم تشغيل backend الخاص بالمنتج لكي تصبح طبقة identity/OAuth الخاصة بـ OpenProof سليمة. غيّر إعدادات gateway/upstream باستخدام sudo openproof config main.

7. TLS وingress

استخدم Let’s Encrypt لاسم DNS عام حقيقي، أو وفّر شهادة موجودة، أو أنهِ TLS عند ingress/load balancer الخاص بك. الأسماء المحجوزة مثل *.example.com, *.test and *.invalid تستخدم TLS خارجيًا/مؤجلًا افتراضيًا بدل طلب شهادة عامة محكوم عليه بالفشل.

8. تحقق من الصحة

sudo openproof status
openproof status --full
sudo openproof doctor

عند فحص listener على loopback يدويًا في وضع trusted-proxy، أرسل عنوان العميل المحلي الممرّر:

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

{"status":"ok"}

الجزء الثاني — التطوير باستخدام 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. سجّل application وclient

يمكن لمالك نشط بمستوى IAL2 استخدام /admin/console أو API الإدارة. اختر نوع client المطابق لمنتجك.

2. استخدم Authorization Code + PKCE

أنشئ verifier عالي entropy وPKCE S256 challenge وقيمة عشوائية لـ state وقيمة عشوائية nonce. عند callback، تحقق من state وissuer المعاد قبل تبادل code.

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 token. تحقق من RS256 مقابل JWKS الخاص بالـ issuer وتحقق من iss, aud, exp, iat والقيمة الأصلية nonce؛ وراعِ أيضًا nbf, azp and at_hash حيثما وُجدت.

4. اعمل بلغتك

5. احمِ واجهات API

سجّل resource مع audience وscopes، ثم تحقق من access token أو استخدم introspection في backend، أو ضع routes خلف OpenProof gateway. اجعل authorization للمنتج أضيق من مجرد «token صالح»: تحقق من audience وscope وسياسة عملك.

6. خدمة إلى خدمة

استخدم service client باستخدام client_credentials. يتلقى access token فقط — بلا جلسة بشرية وبلا refresh token.

قائمة تحقق الإنتاج

• DNS حقيقي وHTTPS موثوق جاهزان.
• توجد نسخ احتياطية لـ PostgreSQL وتم اختبار تمرين restore.
• يستخدم تسليم التحقق SMTP relay/webhook حقيقيًا بدل hostnames تجريبية.
• المالك الأول محمي بـ MFA/TOTP.
• تتطابق callbacks الخاصة بالمزوّدين بدقة مع identity origin في الإنتاج.
• عناوين OAuth redirect URI دقيقة والتحقق من PKCE/state/nonce مفعّل.
• يتم التحقق من توقيع/claims في ID token؛ ويتم تفويض access token وفق audience وscope.
• يتم حفظ تدوير refresh token بشكل ذري.
• تتم مراقبة readiness و openproof doctor ينجح بعد تغييرات البنية التحتية.
• لا تدخل أسرار provider/client/database/signing أبدًا إلى source control أو logs أو prompts الذكاء الاصطناعي.

المرجع