> ## Content Index > Fetch the complete content index at: https://arabroot.io/llms.txt > Use this file to discover other available public pages before exploring further. # ربط Gitea مع authentik عبر OIDC: دخول موحد وإنشاء تلقائي للحسابات وصلاحيات إدارة تتبع المجموعات - URL: https://arabroot.io/articles/ربط-gitea-مع-authentik-عبر-oidc/ - Published: 2026-09-26T15:30:00.000Z - Updated: 2026-10-04T20:05:56.000Z - Description: اجعل موظفيك يدخلون إلى Gitea بحساباتهم في authentik، فتنشأ حساباتهم تلقائياً في أول دخول، وتمنح صلاحية الإدارة أو تسحب بحسب المجموعة التي ينتمون إليها. - Author: فريق عرب رووت - Tags: الأدلة التقنية, الأمن والدخول الموحد, تطبيقات لفريقك, الاستضافة الذاتية, Gitea إذا كنت قد ثبت [authentik](https://arabroot.io/articles/%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-authentik-%D9%84%D9%84%D8%AF%D8%AE%D9%88%D9%84-%D8%A7%D9%84%D9%85%D9%88%D8%AD%D8%AF/) مزوداً للهوية Identity Provider، وثبت بجانبه [Gitea](https://arabroot.io/articles/%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-gitea-%D9%85%D8%B9-docker-compose/) لاستضافة الكود Source Code، فسوف تلاحظ أن الخدمتين لا تعرف إحداهما الأخرى، فكل موظف يحتاج إلى حساب Account وكلمة مرور Password خاصين به في Gitea، وعندما يغادر أحدهم الشركة فعليك أن تتذكر تعطيل حسابه في authentik ثم في Gitea ثم في كل تطبيق آخر، وهذا بالضبط ما وضعنا authentik من أجل أن نتخلص منه. والحل الذي يخطر على البال أولاً هو أن تنشئ حسابات الموظفين في Gitea يدوياً وتطلب منهم استخدام كلمة المرور نفسها، ولكنه يفشل من أول يوم، والسبب أن الحسابين يبقيان منفصلين، فلا تمر كلمة المرور في Gitea على سياسات Policies authentik ولا على المصادقة الثنائية Two-Factor Authentication، وتعطيل الحساب في authentik لا يغير شيئاً في Gitea. وأما الطريقة الصحيحة فهي ربط الخدمتين عبر [**OpenID Connect (OIDC)**](https://openid.net/connect/?ref=arabroot.io)، فيضغط الموظف «Sign in with authentik» ويمر بسياسات authentik ومصادقته الثنائية، وينشئ Gitea حسابه تلقائياً في أول دخول، وعندما تعطل الحساب في authentik لا يستطيع صاحبه الدخول إلى Gitea عبر الويب بعد ذلك. وفي الطريق سوف نجيب عن سؤال يطرحه أغلب مديري الأنظمة System Administrators: من يكون مديراً في Gitea؟ فبدلاً من منح الصلاحية Permission يدوياً لكل شخص، سوف نربطها بالعضوية Membership في مجموعة Group باسم `gitea-admins` داخل authentik، فيمنحها Gitea ويسحبها تلقائياً مع كل دخول. وسوف نناقش في هذا المقال ما يلي: - إنشاء التطبيق Application والمزود Provider في authentik، وما هو عنوان إعادة التوجيه Redirect URI الذي يجب أن يتطابق في الطرفين. - مجموعة مديري Gitea، ولماذا لا تحتاج إلى Property Mapping مخصص لكي يصل اسمها إلى Gitea. - إعداد التسجيل التلقائي Auto Registration وربط الحسابات الموجودة في Gitea، ثم مصدر المصادقة Authentication Source من الواجهة أو من سطر الأوامر. - التحقق من الربط، وما الذي يبقى صالحاً بعد مغادرة الموظف، ثم النسخ الاحتياطي والتحديث وأشهر المشكلات وحلولها. ## المتطلبات - authentik على `https://auth.example.com`، وGitea على `https://git.example.com`، ولكل منهما شهادة Certificate TLS صالحة. - يجب أن يصل الـ Container الخاص بـ Gitea إلى `https://auth.example.com`، والسبب أن Gitea يجلب ملف الاكتشاف Discovery ويستبدل الرموز Tokens من السيرفر Server مباشرة لا من متصفح المستخدم، ويمكنك التحقق من ذلك بالأمر `docker compose exec gitea curl -sI https://auth.example.com/`. - حساب مدير Admin في كل من الخدمتين، واحتفظ بحساب المدير المحلي Local في Gitea (`gitadmin` مثلاً) للطوارئ، لأنك سوف تحتاجه في اليوم الذي يتعطل فيه authentik. ## الإعداد في authentik ### التطبيق والمزود الآن سوف نقوم بإنشاء التطبيق والمزود معاً، فافتح **Applications ← Applications ← New Application** واتبع خطوات [دليل التكامل الرسمي مع Gitea](https://integrations.goauthentik.io/development/gitea/?ref=arabroot.io) كما يلي: 1. **Application:** الاسم `Gitea` والـ slug `gitea`، واحفظ الـ slug لأنه جزء من عنوان الاكتشاف الذي سوف تضعه في Gitea لاحقاً. 2. **Choose a Provider:** [**OAuth2/OpenID Provider**](https://docs.goauthentik.io/add-secure-apps/providers/oauth2/?ref=arabroot.io). 3. **Configure Provider:** - **Authorization Flow:** `default-provider-authorization-implicit-consent`، حتى لا تظهر للموظف شاشة الموافقة Consent Screen مع كل دخول إلى تطبيق داخلي تملكه أنت. - **Client Type:** Confidential، ثم انسخ **Client ID** و**Client Secret**. ![إعداد OAuth2 Provider في authentik مع تدفق التفويض الضمني ونوع العميل Confidential ومعرف العميل وسره](https://arabroot.io/content/images/2026/09/gitea-authentik-01-provider-client.webp) المزود: تدفق التفويض ونوع العميل وبياناته - **Signing Key:** اختر `authentik Self-signed Certificate`، فيوقع authentik الـ ID token بخوارزمية Algorithm RS256 ويعلن المفتاح العام في JWKS لكل تطبيق يتحقق من التوقيع Signature، وإذا تركت الحقل فارغاً فسوف يوقع authentik الرموز بخوارزمية HS256 مستخدماً سر العميل نفسه. ويجدر الإشارة هنا إلى أن Gitea لا يتحقق من توقيع الـ ID token أصلاً، وإنما يتحقق من الـ issuer والـ audience وتاريخ الانتهاء، لأنه يستلم الرمز من authentik مباشرة عبر HTTPS، ولكن المفتاح غير المتماثل هو الخيار الذي يعمل مع كل تطبيق قد تربطه بالمزود نفسه لاحقاً. **Redirect URIs:** اضغط **Add entry** واختر `Strict` و`Authorization`، ثم اكتب العنوان التالي: ```bash https://git.example.com/user/oauth2/authentik/callback ``` ولاحظ أن الجزء `authentik` في المسار هو **اسم مصدر المصادقة** الذي سوف ننشئه في Gitea، فإذا اخترت اسماً آخر فعدل العنوان ليطابقه حرفاً حرفاً. ![حقل Redirect URIs في المزود بوضع Strict ونوع Authorization مع عنوان callback الخاص بـ Gitea](https://arabroot.io/content/images/2026/09/gitea-authentik-02-provider-redirect-uri.webp) عنوان إعادة التوجيه بمطابقة حرفية (Strict) بعد ذلك أنه المعالج Wizard بالضغط على **Create Application**، وفي صفحة المزود سوف تجد كل العناوين التي يحتاجها Gitea، وأهمها **OpenID Configuration URL**، والصورة التالية تبين ذلك: ![صفحة Provider for Gitea في authentik وفيها OpenID Configuration URL والـ Issuer وعناوين authorize وtoken وuserinfo](https://arabroot.io/content/images/2026/09/gitea-authentik-03-provider-endpoints.webp) عنوان الاكتشاف وبقية نقاط OIDC الخاصة بالمزود ### مجموعة مديري Gitea من **Directory ← Groups** أنشئ [مجموعة](https://docs.goauthentik.io/users-sources/groups/?ref=arabroot.io) باسم `gitea-admins` وأضف إليها كل من تريده مديراً في Gitea. وقد يتساءل البعض: كيف يعرف Gitea بهذه المجموعة إذا لم ننشئ [property mapping](https://docs.goauthentik.io/add-secure-apps/providers/property-mappings/?ref=arabroot.io) يرسلها؟ والإجابة أن نطاق Scope `profile` الافتراضي في authentik يرسل أصلاً أسماء مجموعات المستخدم في claim باسم `groups` بجانب الاسم واسم المستخدم، وبالتالي يكفي أن يطلب Gitea هذا النطاق كما سيأتي. 💡 إذا أردت أن يقتصر الوصول إلى Gitea على فريق معين، فاربط مجموعة (مثل `engineering`) بالتطبيق من تبويب **Policy / Group / User Bindings** كما يشرح [دليل إدارة التطبيقات](https://docs.goauthentik.io/add-secure-apps/applications/manage%5Fapps/?ref=arabroot.io)، وعندها سوف يرى من هو خارج المجموعة رسالة «Permission denied» في authentik ولا ينشئ له Gitea حساباً. وإذا كنت تفضل صلاحيات التطبيق Entitlements على المجموعات، ففي [توثيق authentik لتكامل Gitea](https://integrations.goauthentik.io/development/gitea/?ref=arabroot.io) مثال يستخدم scope مخصصاً باسم `gitea`. ## الإعداد في Gitea ### سلوك التسجيل التلقائي أضف المتغيرات Variables التالية إلى خدمة gitea في `docker-compose.yml`، ثم نفذ `docker compose up -d`، وشرح كل منها في قسم [oauth2\_client](https://docs.gitea.com/administration/config-cheat-sheet/?ref=arabroot.io#oauth2-client-oauth2%5Fclient) من مرجع الإعدادات: ```yaml # أنشئ الحساب تلقائيًا في أول دخول عبر authentik GITEA__oauth2_client__ENABLE_AUTO_REGISTRATION: "true" # اسم المستخدم في Gitea = اسم المستخدم في authentik GITEA__oauth2_client__USERNAME: preferred_username # إن وُجد حساب محلي بالبريد نفسه: اطلب كلمة مروره لربطه GITEA__oauth2_client__ACCOUNT_LINKING: login GITEA__oauth2_client__OPENID_CONNECT_SCOPES: "email profile" ``` في الإعداد أعلاه لاحظ التالي: - القيمة الافتراضية لـ `USERNAME` هي `nickname`، وقد اخترنا `preferred_username` لأنه الحقل الذي يضع فيه authentik اسم المستخدم كما هو. - عندما تضبط `OPENID_CONNECT_SCOPES` فإن Gitea يستخدم هذه القائمة لكل مصادر OpenID Connect ويتجاهل حقل Additional Scopes في المصدر نفسه، لذلك يجب أن تحتوي على `profile`، فبدونه لا يصل claim المجموعات. وإذا كنت قد عطلت التسجيل الذاتي Self-Registration في معالج التثبيت (`DISABLE_REGISTRATION = true`) فأبقه معطلاً، والسبب أن التسجيل التلقائي عبر authentik لا يتأثر بهذا الإعداد، وبالتالي ينشئ Gitea حسابات القادمين من authentik ويبقى نموذج التسجيل العادي مغلقاً أمام الزوار. بقي إعداد `ACCOUNT_LINKING`، وهو يحدد ما يحدث عندما يدخل شخص عبر authentik ويوجد في Gitea حساب محلي بنفس اسم المستخدم أو البريد، والجدول التالي يبين الخيارات الثلاثة: | ACCOUNT\_LINKING | ما يحدث إذا وجد حساب محلي بالاسم أو البريد نفسه | | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | disabled | يرفض Gitea إنشاء الحساب ويعرض رسالة خطأ. | | login (الافتراضي) | يطلب Gitea من المستخدم أن يدخل بالحساب المحلي مرة واحدة ليثبت أنه صاحبه، ثم يربط الحسابين. | | auto | يربط Gitea الحسابين تلقائياً بمجرد تطابق الاسم أو البريد، وهو خيار مريح عند نقل مستخدمين موجودين، ولكنه يثق ثقة كاملة بما يرسله authentik، فمن يستطيع تغيير اسمه أو بريده في authentik يستطيع الوصول إلى حساب محلي لا يملكه. | ### مصدر المصادقة افتح **Site Administration ← Identity & Access ← Authentication Sources ← Add Authentication Source** واملأ الحقول Fields كما يلي، وأنواع المصادر المتاحة مشروحة في [دليل المصادقة في Gitea](https://docs.gitea.com/administration/authentication/?ref=arabroot.io): - **Authentication Type:** OAuth2 - **Authentication Name:** `authentik`، ويجب أن يطابق المسار في Redirect URI. - **OAuth2 Provider:** OpenID Connect - **Client ID / Client Secret:** القيمتان اللتان نسختهما من authentik. - **Icon URL:** `https://auth.example.com/static/dist/assets/icons/icon.png` - **OpenID Connect Auto Discovery URL:** `https://auth.example.com/application/o/gitea/.well-known/openid-configuration` - **Additional Scopes:** `email profile`، وهي القيمة نفسها التي وضعناها في `[oauth2_client]`، حتى يبقى المصدر صحيحاً إذا حذفت ذلك المتغير يوماً. ![نموذج Add Authentication Source في Gitea بنوع OAuth2 ومزود OpenID Connect ومعرف العميل وعنوان الاكتشاف](https://arabroot.io/content/images/2026/09/gitea-authentik-04-gitea-auth-source.webp) مصدر مصادقة OpenID Connect في Gitea وفي أسفل النموذج Form نربط الصلاحيات بالمجموعات كما يلي: - **Claim name providing group names for this source:** `groups` - **Group Claim value for administrator users:** `gitea-admins` - **Group Claim value for restricted users:** اختياري، مثل `gitea-restricted` للمتعاقدين، فالمستخدم المقيد Restricted لا يرى إلا المستودعات والمنظمات التي تضيفه إليها صراحة. - **Map claimed groups to Organization teams:** اختياري، ويضيف به Gitea الأعضاء إلى فرق المنظمات تلقائياً، مثل `{"engineering": {"example-org": ["Developers"]}}`. ![حقول group claim في مصدر المصادقة: اسم الـ claim groups وقيمة مجموعة المديرين gitea-admins](https://arabroot.io/content/images/2026/09/gitea-authentik-05-gitea-group-claims.webp) تأتي صلاحية المدير من مجموعة gitea-admins وإذا أردت أن يقتصر الدخول على من يحمل claim معيناً فسوف تجد في النموذج الحقلين **Required Claim Name** و**Required Claim Value**، وتضع فيهما مثلاً `groups` و`engineering`، ولكن الحل الأنسب هو ربط المجموعة بالتطبيق في authentik كما في الملاحظة السابقة، والسبب أن الرفض يقع عندها قبل أن يصل المستخدم إلى Gitea أصلاً، وفي مكان واحد تدير منه كل التطبيقات. وبدلاً من النموذج يمكنك أن تنفذ [أمراً واحداً من سطر الأوامر](https://docs.gitea.com/administration/command-line/?ref=arabroot.io)، وهذا مفيد في الأتمتة Automation أو عند إعادة بناء السيرفر: ```bash docker compose exec -u git gitea gitea admin auth add-oauth \ --name authentik \ --provider openidConnect \ --key "CLIENT_ID" \ --secret "CLIENT_SECRET" \ --auto-discover-url https://auth.example.com/application/o/gitea/.well-known/openid-configuration \ --icon-url https://auth.example.com/static/dist/assets/icons/icon.png \ --scopes "email profile" \ --group-claim-name groups \ --admin-group gitea-admins ``` ## كيف تتحقق من نجاح الربط؟ سجل خروجك Log Out من Gitea ثم افتح صفحة الدخول Login Page، وسوف تجد هذا الزر: ![صفحة دخول Gitea وفيها زر Sign in with authentik بأيقونة authentik](https://arabroot.io/content/images/2026/09/gitea-authentik-06-gitea-login-button.webp) زر الدخول عبر authentik في صفحة Gitea اضغطه وادخل بحساب authentik عادي عضو في `gitea-admins`، وبعد كلمة المرور ورمز TOTP سوف تعود إلى لوحة Dashboard Gitea وقد سجلت دخولك دون أي نموذج تسجيل، حيث ينشئ Gitea الحساب تلقائياً بالبريد والاسم القادمين من authentik ويمنحه صلاحية المدير، كما في الحساب `sara` في الصورة التالية: ![قائمة المستخدمين في Gitea وفيها الحساب sara منشأ تلقائياً بشارة Admin](https://arabroot.io/content/images/2026/09/gitea-authentik-07-sara-auto-registered-admin.webp) أنشأ Gitea الحساب في أول دخول، وجاءت صلاحية المدير من المجموعة والآن لنكسر الإعداد عمداً لنفهمه: أزل `sara` من `gitea-admins` في authentik، وبعد دخولها التالي سوف تصبح قيمة `is_admin` في Gitea `false`، والسبب أن Gitea يعيد مزامنة Sync الصلاحية من claim المجموعات مع كل دخول لا مرة واحدة فقط. ويمكنك التحقق من ذلك بنفسك عبر [الـ API](https://docs.gitea.com/development/api-usage/?ref=arabroot.io) بالأمر التالي: ```bash curl -s -H "Authorization: token ADMIN_TOKEN" https://git.example.com/api/v1/admin/users | jq '.[] | {login, is_admin, source_id}' ``` والقيمة غير الصفرية في `source_id` تعني أن الحساب مرتبط بمصدر authentik، وأما الصفر فيعني حساباً محلياً مثل حساب الطوارئ. ولاحظ أن السحب لا يحدث إلا عند الدخول التالي، فالجلسة المفتوحة في المتصفح تبقى بصلاحيتها القديمة حتى تنتهي أو يسجل صاحبها خروجه. ## ملاحظات أمنية وتشغيلية - **Git عبر HTTPS:** حسابات OIDC لا تملك كلمة مرور في Gitea، لذلك يستخدم المطورون مفاتيح SSH أو **Access Tokens** من إعداداتهم لعمليات git عبر HTTPS. - **المصادقة الثنائية:** فرضها يكون في authentik، والخيار **Skip local 2FA** في المصدر يجعل Gitea لا يطلب مصادقته الثنائية الخاصة فوق authentik، فلا تقم بتفعيله إلا إذا كانت المصادقة الثنائية مفروضة فعلاً في authentik، والسبب أنك بغير ذلك تزيل الطبقة الوحيدة الموجودة. - **مغادرة موظف:** عطل حسابه في authentik فلا يستطيع الدخول عبر الويب، **ولكن تذكر:** مفاتيح SSH والـ Access Tokens التي أنشأها في Gitea تبقى صالحة، لأنها لا تمر على authentik أصلاً، لذلك عطل حسابه في Gitea أيضاً. وفي Gitea مهمة مجدولة باسم Synchronize external user data في عمليات الصيانة تحاول كل ليلة تجديد Refresh Token كل مستخدم من مصادر OAuth2 وتعطل حسابه إذا رفض المزود التجديد، ولكنها لا تعمل إلا إذا أصدر authentik رمز تجديد، وهو لا يصدره إلا إذا طلب Gitea النطاق `offline_access`، لذلك لا تعتمد عليها بدلاً من التعطيل اليدوي. - **حساب الطوارئ:** احتفظ بحساب مدير محلي في Gitea بكلمة مرور قوية ومصادقة ثنائية، واحفظ بياناته في مدير كلمات المرور Password Manager. 📌 في 4 أبريل 2022 أعلنت شركة Block المالكة لتطبيق Cash App في [إفصاح رسمي لهيئة الأوراق المالية الأمريكية](https://www.sec.gov/Archives/edgar/data/1512673/000119312522095215/d343042d8k.htm?ref=arabroot.io) أن موظفاً سابقاً نزل في 10 ديسمبر 2021 تقارير من Cash App Investing فيها بيانات عملاء أمريكيين، وكان يصل إلى هذه التقارير بحكم عمله، ولكنه وصل إليها هذه المرة بعد انتهاء خدمته، واضطرت الشركة إلى إبلاغ نحو 8.2 مليون عميل حالي وسابق. والدرس هنا أن مغادرة الموظف لا تنتهي بتعطيل حسابه الرئيسي، وإنما بإغلاق كل باب كان يدخل منه، ومنها مفاتيح SSH والرموز في Gitea. ## النسخ الاحتياطي (Backup) والاستعادة (Restore) إعداد مصدر المصادقة وارتباطات المستخدمين Account Links محفوظة في قاعدة بيانات Database Gitea، والأمر [gitea dump](https://docs.gitea.com/administration/backup-and-restore/?ref=arabroot.io) يشملها، وأما المزود والتطبيق والمجموعة فهي في قاعدة بيانات authentik، لذلك تحتاج إلى النسختين معاً. وإذا أعدت إنشاء المزود في authentik من الصفر فسوف يتغير Client ID والسر Secret، فحدثهما في Gitea من **Authentication Sources ← authentik**. وأما ارتباط الحسابات فيعتمد على claim `sub`، وقيمته في authentik افتراضياً hash ثابت لمعرف المستخدم User ID، وبالتالي يبقى الارتباط صالحاً ما دام المستخدمون أنفسهم موجودين، أي ما دمت استعدت قاعدة authentik نفسها ولم تنشئ المستخدمين من جديد. ## التحديث (Upgrade) إلى إصدار (Release) أحدث حدث كل خدمة وفق دليلها، وبعد تحديث authentik خصوصاً راجع قسم OAuth2 في [ملاحظات الإصدار](https://docs.goauthentik.io/releases/?ref=arabroot.io)، فمثلاً منذ [الإصدار 2025.10](https://docs.goauthentik.io/releases/2025.10/?ref=arabroot.io) يرسل authentik `email_verified` بالقيمة `false` افتراضياً، وفي الإصدار 2026.5 صارت Redirect URIs مصنفة إلى Authorization وPost Logout. وGitea لا يشترط قيمة `email_verified`، ولكن بعض التطبيقات الأخرى تشترطها، لذلك بعد كل تحديث جرب الدخول عبر الزر من نافذة خاصة في المتصفح قبل أن يكتشف الموظفون المشكلة بأنفسهم. ## مشكلات شائعة وحلولها (Troubleshooting) ### authentik يعرض «Redirect URI Error» العنوان الذي أرسله Gitea لا يطابق العنوان المسجل حرفياً، والسبب الأشهر أن اسم المصدر في Gitea يختلف عن المسار (`/user/oauth2//callback`)، أو أن `ROOT_URL` في Gitea ما زال يبدأ بـ `http://` أو يتضمن منفذاً Port، والحل أن تصحح `ROOT_URL` أو تنسخ العنوان الذي يرسله Gitea كما هو إلى المزود. ### Gitea يرفض حفظ المصدر أو يفشل الدخول بخطأ في الاكتشاف الـ Container الخاص بـ Gitea لا يصل إلى authentik، أو أن الشهادة غير موثوقة داخله، وللتأكد نفذ الأمر `docker compose exec gitea curl -s https://auth.example.com/application/o/gitea/.well-known/openid-configuration`، فإذا لم يظهر لك ملف JSON وكان النطاق Domain داخلياً فأضف [extra\_hosts](https://docs.docker.com/reference/compose-file/services/?ref=arabroot.io#extra%5Fhosts) إلى خدمة gitea. ### «issuer in token does not match issuer in OpenIDConfig discovery» يبني authentik قيمة الـ issuer من العنوان الذي وصل عبره الطلب، فإذا جلب Gitea ملف الاكتشاف عبر عنوان داخلي (مثل `http://authentik-server-1:9000`) واستخدم المتصفح العنوان العام فسوف يختلف الـ issuer بينهما، والحل أن تستخدم العنوان العام نفسه في الحالتين. وإذا ظهر الـ issuer في ملف الاكتشاف بـ `http://` رغم أنك تستخدم العنوان العام، فالسبب غالباً أن الـ Reverse Proxy ليس ضمن الشبكات الموثوقة في `AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS`، فمنذ [الإصدار 2026.8](https://docs.goauthentik.io/releases/2026.8/?ref=arabroot.io) يتجاهل authentik ترويسات `X-Forwarded-Proto` القادمة من خارج هذه الشبكات. ### اسم المستخدم في Gitea يختلف عنه في authentik، أو يطلب Gitea نموذج تسجيل راجع قيمة `USERNAME` في `[oauth2_client]`، فإذا كان اسم المستخدم في authentik بريداً إلكترونياً، كما يحدث بعد الربط مع Google مثلاً، فلن يقبله Gitea اسماً للمستخدم، وفي هذه الحالة استخدم `USERNAME: email` ليأخذ Gitea الجزء الذي يسبق `@`، أو أنشئ property mapping في authentik يرسل قيمة مناسبة في `preferred_username`. ويظهر نموذج التسجيل أيضاً إذا لم يصل أحد الحقول المطلوبة، وفي هذه الحالة سوف تجد في سجلات Logs Gitea رسالة تذكر اسم الحقل الناقص. ### المستخدم لا يصبح مديراً افتح المزود في authentik ثم تبويب **Preview** واختر المستخدم، وتأكد أن `groups` يتضمن `gitea-admins` بالحروف نفسها، ثم تأكد أن `profile` موجود ضمن النطاقات التي يطلبها Gitea، أي في `OPENID_CONNECT_SCOPES` إذا ضبطته، وإلا ففي Additional Scopes في المصدر، فمعه يصل claim المجموعات. ## الخلاصة وصلنا لنهاية الموضوع، وأهم ما فيه: - الربط عبر OIDC يجعل authentik المكان الوحيد الذي تدير منه الدخول إلى Gitea، ويكفيه مزود واحد عنوان إعادة التوجيه فيه `/user/oauth2//callback` مطابق لاسم المصدر في Gitea. - لا تحتاج إلى property mapping لمجموعة المديرين، لأن نطاق `profile` يرسل claim `groups`، ولكن تأكد أن Gitea يطلبه، وتذكر أن `OPENID_CONNECT_SCOPES` يتقدم على Additional Scopes في المصدر. - صلاحية المدير تأتي من `gitea-admins` وتتجدد مع كل دخول، فتمنحها وتسحبها من authentik وحده. - اترك `ACCOUNT_LINKING` على `login` إلا إذا كنت تنقل مستخدمين موجودين وتثق بما يرسله authentik. - تعطيل الحساب في authentik لا يبطل مفاتيح SSH والرموز في Gitea، لذلك عطل الحساب في Gitea أيضاً عند مغادرة أي موظف، واحتفظ بحساب مدير محلي للطوارئ. ## سجل التحديثات - سبتمبر 2026: كتابة الدليل واختباره على [Gitea 1.27.3](https://github.com/go-gitea/gitea/releases/tag/v1.27.3?ref=arabroot.io) و[authentik 2026.8.3](https://github.com/goauthentik/authentik/releases/tag/version/2026.8.3?ref=arabroot.io). - أكتوبر 2026: مراجعة تقنية، صححنا فيها أن Gitea لا يتحقق من توقيع الـ ID token وإنما من الـ issuer والـ audience، وأن `OPENID_CONNECT_SCOPES` يتقدم على Additional Scopes في المصدر، وأن الخيار `auto` يربط بالاسم أو البريد، وأن مزامنة المستخدمين في Gitea تحتاج إلى `offline_access`، وأضفنا نص رسالة خطأ الـ issuer وأثر `AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS`.