> ## 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.

# تسجيل الدخول بحساب Google في authentik وقصره على نطاق مؤسستك
- URL: https://arabroot.io/articles/تسجيل-الدخول-بحساب-google-في-authentik/
- Published: 2026-09-25T07:25:00.000Z
- Updated: 2026-10-04T20:05:59.000Z
- Description: يملك موظفوك حسابات Google، فلماذا يحتاجون إلى كلمة مرور جديدة؟ نضيف زر الدخول بحساب Google إلى authentik، ونقصر التسجيل على نطاق مؤسستك وحده.
- Author: فريق عرب رووت
- Tags: الأدلة التقنية, الأمن والدخول الموحد, الاستضافة الذاتية, authentik

إذا كانت مؤسستك تعمل على [Google Workspace](https://workspace.google.com/?ref=arabroot.io) فلكل موظف عندك حساب Google تديره من لوحة Workspace ويحميه التحقق الثنائي 2FA، وعندما تشغل [authentik](https://goauthentik.io/?ref=arabroot.io) للدخول الموحد SSO إلى تطبيقاتك كما شرحنا في [دليل تثبيت 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/) فسوف تجد أمامك طريقتين لحسابات الموظفين: الأولى أن تنشئ لكل موظف حساباً محلياً Local Account في authentik بكلمة مرور Password جديدة، والثانية أن يدخل الموظف بحساب Google الذي يملكه أصلاً.

والطريقة الأولى هي التي تخطر على البال أولاً، ولكنها تعني كلمة مرور إضافية سوف ينساها الموظف بعد أسبوع، وسوف تعيد تعيينها له مرة بعد مرة، وأما في الطريقة الثانية فيختار الموظف «Continue with Google» في صفحة الدخول Login Page في authentik، فينشئ authentik حسابه تلقائياً في المرة الأولى، ثم يصل بهذا الحساب إلى Gitea وOutline وكل تطبيق ربطته بـ authentik دون أن يحفظ كلمة مرور جديدة.

وهذا الدليل عن الطريقة الثانية، حيث نضيف Google [Source للهوية](https://docs.goauthentik.io/users-sources/sources/?ref=arabroot.io) إلى authentik، ثم نضبط ثلاثة أمور لا يعالجها الإعداد الافتراضي كما تتوقع: اسم المستخدم Username، لأن Google لا ترسل اسم مستخدم أصلاً، وقصر التسجيل Enrollment على نطاق Domain مؤسستك، حتى لا يدخل أي صاحب حساب Gmail، ونوع الحساب، لأن authentik ينشئ مستخدمي المصادر افتراضياً من النوع External.

ولا تناسبك هذه الطريقة إذا كان بعض أفراد فريقك لا يملكون حسابات Google، أو كانت سياسة مؤسستك تمنع الاعتماد على مزود هوية Identity Provider خارجي، وفي هذه الحالة ابق على الحسابات المحلية في authentik مع TOTP.

وسوف نناقش في هذا المقال ما يلي:

- كيف يعمل الربط بين authentik وGoogle، وما هو عنوان الرجوع Callback URL الذي يجب أن يتطابق في الطرفين.
- إنشاء عميل OAuth في Google Cloud Console، والفرق بين Internal وExternal وأثره على من يستطيع الدخول.
- إنشاء Google Source في authentik وإظهار زره في صفحة الدخول.
- استخراج اسم المستخدم من البريد، وقصر الدخول على نطاق مؤسستك بالطريقة الصحيحة، ولماذا لا يكفي فحص نهاية البريد.
- إنشاء الحسابات مستخدمين داخليين، ثم التحقق والنسخ الاحتياطي والتحديث وأشهر المشكلات وحلولها.

## المتطلبات

- سيرفر Server عليه authentik يعمل على نطاق عام عبر HTTPS، مثل `https://auth.example.com` (انظر [دليل تثبيت 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/))، والسبب أن Google [لا تقبل عناوين إعادة التوجيه عبر HTTP](https://developers.google.com/identity/protocols/oauth2/web-server?ref=arabroot.io#uri-validation) إلا لـ `localhost`.
- حساب Google يملك صلاحية Permission إنشاء مشروع في [Google Cloud Console](https://console.cloud.google.com/?ref=arabroot.io)، والأفضل أن يكون حساب مدير Admin في Workspace مؤسستك، لأن الخيار Internal الذي سوف نشرحه لا يظهر إلا لمشروع تابع لمؤسسة.
- صلاحية مدير في authentik.

## كيف يعمل الربط؟

authentik هنا **عميل OAuth** لدى Google، فعندما ينقر الموظف الزر يرسله authentik إلى Google، وبعد أن يدخل ويوافق تعيده Google إلى عنوان callback في authentik ومعه رمز التفويض Authorization Code، فيستبدل authentik هذا الرمز بتوكن Access Token ثم يطلب به بيانات المستخدم من Google، أي معرفه الفريد Unique Identifier والبريد والاسم، ومعها الحقل `hd` إذا كان الحساب تابعاً لمؤسسة على Workspace، وهذا الحقل سوف نعتمد عليه لاحقاً. وبعد ذلك يمر المستخدم بواحد من [الـ Flows](https://docs.goauthentik.io/add-secure-apps/flows-stages/flow/?ref=arabroot.io) التالية:

- **Enrollment flow** (`default-source-enrollment`) في الدخول الأول، وفيه ينشئ authentik الحساب.
- **Authentication flow** (`default-source-authentication`) في المرات التالية، وفيه يدخل المستخدم إلى حسابه المرتبط.

وعنوان الـ callback ثابت وصيغته `https://auth.example.com/source/oauth/callback/<slug>/`، حيث الـ slug هو الاسم المختصر الذي سوف تعطيه للـ Source في authentik، وسوف نستخدم `google`، فيصبح العنوان كما يلي:

```bash
https://auth.example.com/source/oauth/callback/google/
```

## ما الذي تضبطه في Google Cloud Console؟

💡

تغير Google أسماء القوائم في Cloud Console من حين إلى آخر، والخطوات التالية تتبع الواجهة الحالية [Google Auth Platform](https://support.google.com/cloud/answer/15544987?ref=arabroot.io)، فإذا اختلف اسم إحدى القوائم فابحث عنه في شريط البحث أعلى الصفحة.

1. ادخل إلى `console.cloud.google.com` واختر **New Project** من محدد المشاريع أعلى الصفحة، وسمه مثلاً `authentik-sso`، وإذا كانت لديك Workspace فاختر مؤسستك في حقل Organization، لأن المشروع الذي لا يتبع مؤسسة لا يملك الخيار Internal.
2. افتح **Google Auth Platform** من القائمة (واسمها السابق OAuth consent screen)، وانقر **Get started**:
  - **App name:** الاسم الذي يراه الموظف في شاشة الموافقة Consent Screen، مثل «دخول شركة المثال».
  - **User support email:** بريد الدعم.
  - **Audience:** اختر **Internal** إذا كان المشروع داخل Workspace مؤسستك، وبهذا ترفض Google نفسها أي حساب من خارج المؤسسة قبل أن يصل إلى authentik أصلاً، وهذا أقوى قيد متاح لك. ولا تختر **External** إلا إذا أردت السماح بحسابات Gmail أو لم تكن لديك Workspace، وانتبه هنا إلى أمر يخطئ فيه كثيرون: وضع Testing وقائمة Test users [لا تحميك في هذا الإعداد](https://support.google.com/cloud/answer/15549945?ref=arabroot.io)، والسبب أن Google تستثني التطبيقات التي لا تطلب إلا الاسم والبريد والملف الشخصي من قائمة المختبرين، وهذا بالضبط ما يطلبه authentik، وبالتالي يستطيع أي صاحب حساب Google أن يدخل ولو كان التطبيق في وضع Testing، لذلك فسياسة النطاق التي سوف نضيفها لاحقاً إلزامية مع External.
  - **Contact information:** بريد تصلك عليه تنبيهات Google الخاصة بالمشروع.
3. في [**Branding**](https://support.google.com/cloud/answer/10311615?ref=arabroot.io) أضف `example.com` إلى **Authorized domains**.
4. افتح [**Clients**](https://support.google.com/cloud/answer/15549257?ref=arabroot.io) ثم **Create client**:
  - **Application type:** Web application.
  - **Name:** `authentik`.
  - **Authorized redirect URIs:** أضف `https://auth.example.com/source/oauth/callback/google/` كما هو تماماً، ومعه الشرطة المائلة Trailing Slash في آخره، والسبب أن Google تقارن العنوان حرفاً حرفاً.
5. انقر **Create** وانسخ **Client ID** و**Client secret** فوراً، واحفظ السر في مدير كلمات المرور Password Manager، والسبب أن Google [تحفظ السر بعد الهاش Hash](https://support.google.com/cloud/answer/15549257?ref=arabroot.io#client-secret-hashing) ولا تعرضه كاملاً إلا مرة واحدة عند إنشائه، ثم لا ترى منه بعد ذلك إلا آخر أربعة أحرف.

ولا تحتاج إلى تفعيل أي API إضافية، لأن authentik لا يطلب من Google إلا [صلاحيتي الوصول Scopes](https://developers.google.com/identity/protocols/oauth2/scopes?ref=arabroot.io) `email` و`profile`، وهما من الصلاحيات غير الحساسة التي لا تمر بمراجعة الصلاحيات الحساسة Sensitive Scopes، وأما مع Internal فالتطبيق معفى من [متطلبات التحقق](https://support.google.com/cloud/answer/13464321?ref=arabroot.io) كلها لأن مستخدميه من داخل مؤسستك فقط.

## كيف تضيف Google Source إلى authentik؟

الآن سوف نقوم بإنشاء الـ Source، فمن لوحة الإدارة Admin Panel افتح **Directory ← Federation and Social login** وانقر **New Source** واختر [**Google OAuth Source**](https://docs.goauthentik.io/users-sources/sources/social-logins/google/cloud/?ref=arabroot.io)، ثم املأ الحقول كما يلي:

- **Source Name:** `Google`، و**Slug:** `google`، ويجب أن يطابق الـ slug الجزء الأخير من عنوان الـ callback المسجل في Google.
- **Promoted:** فعله ليظهر الـ Source زراً عريضاً بعرض الصفحة بدلاً من أيقونة صغيرة.
- **User matching mode:** يحدد ما يحدث إذا دخل شخص بحساب Google بريده هو بريد حساب محلي موجود، والخيار الافتراضي *Link users on unique identifier* ينشئ حساباً جديداً مرتبطاً بمعرف Google الفريد للحساب، وهو الأكثر أماناً، وأما *Link to a user with identical email address* فيربط الدخول بالحساب المحلي الذي له البريد نفسه، وهذا يناسبك إذا كان موظفوك مسجلين في authentik من قبل، ولكن تذكر أن من يملك هذا البريد في Google يملك الحساب المحلي، لذلك لا تستخدمه إلا مع Audience = Internal أو مع سياسة النطاق مربوطة بالـ Flow الخاص بالدخول أيضاً كما سيأتي.

📌

في 13 يناير 2025 نشر Dylan Ayrey من شركة Truffle Security [بحثاً](https://trufflesecurity.com/blog/millions-at-risk-due-to-google-s-oauth-flaw?ref=arabroot.io) اشترى فيه نطاق شركة ناشئة أغلقت أبوابها، وأعاد إنشاء حسابات موظفيها السابقين على Google Workspace، ثم دخل بزر «Sign in with Google» إلى حساباتهم في ChatGPT وSlack وNotion وZoom ونظام موارد بشرية فيه أرقام ضمان اجتماعي، والسبب أن هذه الخدمات كانت تثق بالبريد وبالحقل `hd` وحدهما، وهما يقولان من يملك النطاق اليوم لا من كان صاحب الحساب بالأمس، ووجد في قاعدة Crunchbase [نحو 116 ألف نطاق](https://techcrunch.com/2025/01/19/employees-of-failed-startups-are-at-special-risk-of-stolen-personal-data-through-old-google-logins/?ref=arabroot.io) لشركات متوقفة معروضة للشراء، وقد أغلقت Google البلاغ أولاً بوصف Won't fix ثم أعادت فتحه ومنحته مكافأة 1,337 دولاراً. والدرس هنا أن الربط بمعرف Google الفريد أسلم من الربط بالبريد، وأن نطاق مؤسستك يجب ألا ينتهي تسجيله ما دامت حساباتها حية في أي نظام.

![نموذج إنشاء Google OAuth Source بالاسم Google والـ slug google مع خيار Promoted ووضع مطابقة المستخدمين](https://arabroot.io/content/images/2026/09/authentik-google-01-google-source-general.webp)

الإعدادات العامة للـ Source

وفي **Protocol settings** الصق Client ID في **Consumer key** وClient secret في **Consumer secret**، واترك حقل Scopes فارغاً لأنك لا تحتاج إلى أكثر من الاسم والبريد، وفي أسفل النموذج سوف تجد أن authentik اختار تلقائياً `default-source-authentication` و`default-source-enrollment` للـ Flow الخاص بالدخول والـ Flow الخاص بالتسجيل، فاتركهما كما هما.

![حقول Consumer key وConsumer secret وScopes في إعدادات بروتوكول الـ Source](https://arabroot.io/content/images/2026/09/authentik-google-02-google-source-keys.webp)

بيانات عميل OAuth من Google (القيم في الصورة تجريبية)

وبعد الحفظ افتح صفحة الـ Source وقارن **Callback URL** الظاهر فيها بما أدخلته في Google حرفاً حرفاً، ولاحظ أن العنوان في بيئة الإنتاج Production يجب أن يبدأ بـ `https://auth.example.com` لا بعنوان محلي كالذي في الصورة، فإذا ظهر لك بـ `http` فالمشكلة في الـ Reverse Proxy كما سيأتي في قسم المشكلات.

![صفحة تفاصيل Google Source وفيها Callback URL وعناوين التفويض والرمز الخاصة بـ Google ومخطط الـ Flows](https://arabroot.io/content/images/2026/09/authentik-google-03-source-callback-url.webp)

عنوان callback الذي يجب أن يطابق Authorized redirect URI في Google

## كيف يظهر الزر في صفحة الدخول؟

إنشاء الـ Source وحده لا يضعه في صفحة الدخول، لذلك افتح **Flows and Stages ← Stages** وعدل [الـ Stage](https://docs.goauthentik.io/add-secure-apps/flows-stages/stages/identification/?ref=arabroot.io) المسماة `default-authentication-identification`، ثم في قسم **Source settings** انقل `Google` إلى **Selected Sources**، وفعل **Show sources' labels** إذا أردت أن يظهر الاسم بجانب الأيقونة.

![قسم Source settings في Identification Stage مع اختيار Google Source](https://arabroot.io/content/images/2026/09/authentik-google-04-identification-stage-sources.webp)

ربط الـ Source بالـ Identification Stage في Flow الدخول الافتراضي

والآن افتح صفحة الدخول في نافذة خاصة Private Window، وسوف تجد الزر تحت حقل اسم المستخدم:

![صفحة دخول authentik وفيها زر Continue with Google أسفل زر Log in](https://arabroot.io/content/images/2026/09/authentik-google-05-login-google-button.webp)

صفحة الدخول بعد إضافة الـ Source

وإذا أردت أن يكون الدخول عبر Google وحده فألغ تحديد **Username** و**Email** في **User Fields** في الـ Stage نفسها، فلا يبقى في الصفحة إلا زر Google، ولكن لا تقم بذلك قبل أن تتأكد أن حساب مدير واحداً على الأقل يدخل عبر Google ويملك صلاحيات الإدارة، والسبب أن أي خطأ في إعداد Google بعدها سوف يغلق الباب على الجميع وأنت منهم، واحتفظ أيضاً بطريقة الطوارئ [ak create\_recovery\_key](https://docs.goauthentik.io/troubleshooting/login/?ref=arabroot.io) المشروحة في دليل التثبيت.

## كيف يستخرج authentik اسم المستخدم من البريد؟

Google لا ترسل اسم مستخدم، لذلك يعرض authentik في الدخول الأول صفحة تطلب من الموظف أن يختار اسماً لنفسه، وهذا هو الحل الافتراضي، وهو يفشل في أول أسبوع لأنك سوف تجد في قائمة المستخدمين `ahmed` و`a.ali` و`ahmed_2026` بلا نمط واحد. والحل الثاني الذي يذكره [التوثيق الرسمي Documentation](https://docs.goauthentik.io/users-sources/sources/social-logins/google/cloud/?ref=arabroot.io) هو Property Mapping على الـ Source تعيد البريد اسماً للمستخدم، ولكن التوثيق نفسه ينبه إلى أنها تعمل مع كل دخول وقد تغير أسماء المستخدمين الموجودين، وأما الحل الأنسب في رأينا فهو [سياسة Expression](https://docs.goauthentik.io/customize/policies/types/expression/?ref=arabroot.io) تعمل مرة واحدة عند التسجيل، فتكتب الجزء الذي قبل `@` في حقل اسم المستخدم قبل عرض تلك الصفحة، فيتخطاها authentik ولا يمس الاسم بعد ذلك.

من **Customization ← Policies** انقر **New Policy** واختر **Expression Policy**، وسمها `google-username-from-email`، وضع فيها الكود التالي:

```python
email = request.context["prompt_data"]["email"]
# use the part before @ as the username
request.context["prompt_data"]["username"] = email.split("@")[0]
return False
```

![إنشاء Expression Policy باسم google-username-from-email وفيها كود تعيين اسم المستخدم من البريد](https://arabroot.io/content/images/2026/09/authentik-google-06-username-policy.webp)

سياسة تعيين اسم المستخدم

ولاحظ أن السياسة تعيد `False` عمداً، فهي لا تقرر شيئاً وكل عملها أن تعدل البيانات، وبعد ذلك اربطها في موضعها الصحيح: **Flows and Stages ← Flows ← default-source-enrollment ← Stage Bindings**، ثم وسع ربط الـ Stage الأولى `default-source-enrollment-prompt` وانقر **Bind existing policy/group/user** واختر السياسة، واجعل ترتيبها Order أصغر من ترتيب السياسة الموجودة `default-source-enrollment-if-username`، مثل `-1`، والسبب أن تلك السياسة تفحص هل وصل اسم المستخدم أم لا، فيجب أن تعمل سياستنا قبلها حتى تجده.

وقد يكون في مؤسستك موظفان بالاسم نفسه على نطاقين مختلفين فيتعارض اسما المستخدمين، وفي هذه الحالة اجعل البريد كاملاً اسماً للمستخدم بتغيير السطر الثالث إلى `= email`.

## كيف تقصر الدخول على نطاق مؤسستك؟

إذا اخترت Audience = Internal في Google فلن يصل إلى authentik إلا أصحاب حسابات مؤسستك، وأما مع External فيستطيع أي صاحب حساب Google أن ينشئ لنفسه حساباً في authentik، ولذلك نحتاج إلى سياسة تفحص النطاق، وهنا يقع كثيرون في خطأين:

- **الاعتماد على المعامل `hd` في رابط Google:** بعض الأدلة تضيف `hd=example.com` إلى رابط التفويض، ولكن Google تقول صراحة إن هذا المعامل [تحسين للواجهة فقط](https://developers.google.com/identity/openid-connect/openid-connect?ref=arabroot.io#hd-param) يرتب قائمة الحسابات، ولا يصح الاعتماد عليه لأن المستخدم يستطيع تعديل الطلب من متصفحه.
- **فحص نهاية البريد:** أي أن يكون البريد منتهياً بـ `@example.com`، وهذا ما تفعله أمثلة كثيرة، ولكن Google تنص على أنك [لا تستطيع الاعتماد على نطاق البريد](https://developers.google.com/identity/openid-connect/openid-connect?ref=arabroot.io#id%5Ftoken-hd) لمعرفة أن الحساب تابع لمؤسسة على Workspace، والسبب أن أي شخص يستطيع [إنشاء حساب Google شخصي ببريد ليس من Gmail](https://support.google.com/accounts/answer/27441?ref=arabroot.io) بعد أن يؤكده برمز يصله، فالموظف الذي أنشأ حساباً شخصياً ببريد العمل وهو في الشركة يبقى الحساب معه بعد أن يغادرها، ولا تستطيع تعطيله من لوحة Workspace.

والطريقة الصحيحة هي فحص الحقل `hd` في البيانات التي يجلبها authentik من Google بنفسه، فهذا الحقل لا تضعه Google إلا للحسابات التي تديرها مؤسسة على Workspace، وقيمته هي نطاق تلك المؤسسة، ولا يستطيع المستخدم تغييره لأنه يأتي من Google مباشرة إلى السيرفر، ويضعه authentik في سياق Context الـ Flow باسم `oauth_userinfo`. لذلك أضف سياسة ثانية باسم `google-only-company-domain` كما يلي:

```python
userinfo = request.context.get("oauth_userinfo", {})
# Google sets hd only for accounts managed by a Workspace organization
if userinfo.get("hd") == "example.com":
    return True
ak_message("Only example.com accounts can sign in.")
return False
```

في الإعداد أعلاه لاحظ التالي:

- استخدمنا `get` بدلاً من الأقواس المربعة، والسبب أن الحساب الشخصي لا يحمل الحقل `hd` أصلاً، فتعود القيمة فارغة ويرفض الشرط بدلاً من أن تفشل السياسة بخطأ.
- المقارنة بالمساواة التامة لا بنهاية النص، فلا يمر نطاق مثل `notexample.com`، وإذا كانت مؤسستك على أكثر من نطاق فاجعل الشرط `in` على قائمة النطاقات.
- الدالة `ak_message` تعرض الرسالة للمستخدم عند الرفض، حتى يعرف السبب بدلاً من صفحة خطأ عامة.

وهذه المرة اربط السياسة بالـ Flow نفسه لا بواحدة من الـ Stages فيه: **Flows ← default-source-enrollment ← Policy / Group / User Bindings ← Bind existing policy**، فإذا لم يحقق الحساب شرط السياسة رفض authentik التسجيل وعرض الرسالة. ويمكنك أن تجرب السياسة قبل أي دخول فعلي من زر **Test** بجانبها في قائمة السياسات، حيث تضع في حقل Context القيمة `{"oauth_userinfo": {"hd": "example.com"}}` فتظهر النتيجة Passing، ثم تحذف `hd` فتظهر النتيجة مرفوضة ومعها الرسالة.

وقد يتساءل البعض: لماذا نضيف سياسة النطاق إذا كان Audience = Internal يمنع الغرباء من الأساس؟ والإجابة أن الإعداد في Google يتغير من شخص لآخر ومن سنة لأخرى، فقد يحول أحدهم المشروع إلى External لاحقاً لكي يدخل متعاقد بحساب Gmail، وفي ذلك اليوم سوف تكون السياسة هي الحاجز الوحيد بين أي حساب Google وبين تطبيقاتك، وكلفتها خمسة أسطر.

⚠️

سياسة النطاق لا تمنع إلا **إنشاء** حسابات جديدة، فإذا كان الـ Source قد أنشأ حسابات قبل إضافتها فراجع **Directory ← Users** وعطل الحسابات التي لا ينبغي وجودها، وإذا كنت تستخدم الـ Source لربط حسابات قائمة عبر البريد (email\_link) فاربط السياسة نفسها بالـ Flow `default-source-authentication` أيضاً، والسبب أن الربط بالبريد يمر بالـ Flow الخاص بالدخول لا بالتسجيل.

## اجعل حسابات الموظفين مستخدمين داخليين (Internal Users)

الـ Stage المسماة `default-source-enrollment-write` هي التي تنشئ الحساب، وهي مضبوطة افتراضياً على النوع **External** المخصص للعملاء والمتعاقدين، فإذا كان الـ Source لموظفيك فعدلها من **Flows and Stages ← Stages** واجعل [**User type**](https://docs.goauthentik.io/add-secure-apps/flows-stages/stages/user%5Fwrite/?ref=arabroot.io) \= **Internal**، ومن الشاشة نفسها يمكنك اختيار **Group** ينضم إليه كل حساب جديد تلقائياً، مثل `employees`، ثم تبني عليه صلاحيات الوصول إلى التطبيقات بدلاً من أن تضيف كل موظف يدوياً.

![تعديل User Write Stage مع اختيار نوع المستخدم Internal وحقل المجموعة الافتراضية](https://arabroot.io/content/images/2026/09/authentik-google-07-source-enrollment-internal-users.webp)

ينشئ authentik الحسابات القادمة من Google مستخدمين داخليين

## التحقق من النجاح

- بعد الموافقة في Google تعود إلى authentik مسجلاً دون أن يطلب منك اسم مستخدم، وفي **Directory ← Users** سوف تجد حساباً جديداً يحمل الجزء الأول من بريدك ونوعه Internal، وفي تبويب **Sources** تجد اتصالاً بـ Google.
- الدخول بحساب Gmail شخصي يفشل مع الرسالة «Only example.com accounts can sign in.»، أو تمنعه Google نفسها إذا كان Audience = Internal.
- في [**Events ← Logs**](https://docs.goauthentik.io/sys-mgmt/events/?ref=arabroot.io) يظهر الحدث `Source linked` ثم الحدث `Login`.

انقر «Continue with Google» في نافذة خاصة، ويجب أن تنتقل إلى `accounts.google.com` وأن يحتوي الرابط على `redirect_uri=https%3A%2F%2Fauth.example.com%2Fsource%2Foauth%2Fcallback%2Fgoogle%2F`، ويمكنك التحقق من ذلك بلا متصفح بالأمر التالي:

```bash
curl -s -o /dev/null -w '%{redirect_url}\n' https://auth.example.com/source/oauth/login/google/
```

والمخرج سوف يكون رابط تحويل Redirect إلى Google فيه معرف العميل وعنوان الـ callback الصحيحان.

## النسخ الاحتياطي والاستعادة (Restore)

الـ Source والسياسات وربط المستخدمين بحساباتهم في Google كلها محفوظة في قاعدة بيانات Database الخاصة بـ authentik، لذلك يكفيك النسخ الاحتياطي Backup المعتاد لـ PostgreSQL (انظر دليل التثبيت)، واحفظ Client ID وClient secret في مدير كلمات المرور، وإذا فقدت السر فأنشئ سراً جديداً للعميل نفسه في Google وحدثه في الـ Source، ولن يتأثر ربط المستخدمين، والسبب أنه مبني على معرف Google الفريد لا على السر.

## التحديث (Upgrade) إلى إصدار أحدث

تحديث authentik لا يحتاج إلى خطوات خاصة بهذا الإعداد، ولكن راجع في [ملاحظات الإصدار](https://docs.goauthentik.io/releases/?ref=arabroot.io) ما يخص الـ Sources والـ Flows الافتراضية، لأن authentik يدير هذه الـ Flows عبر [blueprints](https://docs.goauthentik.io/customize/blueprints/?ref=arabroot.io) وقد تتغير خطواتها، وإذا عدلت Stage افتراضية كما فعلنا مع `default-source-enrollment-write` فتأكد بعد كل تحديث أن تعديلك ما زال قائماً. ومن جهة Google تابع بريد جهة الاتصال، لأن Google [تحذف عملاء OAuth](https://support.google.com/cloud/answer/15549257?ref=arabroot.io#unused-client-deletion) الذين لم يستخدموا ستة أشهر، وترسل تنبيهاً قبل الحذف بثلاثين يوماً، وهذا يحدث عادة لسيرفر الاختبار لا لسيرفر يدخل منه الموظفون كل يوم.

## مشكلات شائعة وحلولها (Troubleshooting)

### تعرض Google رسالة «Error 400: redirect\_uri\_mismatch»

العنوان الذي أرسله authentik لا يطابق أياً من Authorized redirect URIs، وأشيع الأسباب ثلاثة: شرطة مائلة ناقصة في آخر العنوان، أو `http` بدلاً من `https` لأن الـ Reverse Proxy لا يمرر `X-Forwarded-Proto` أو لأن عنوانه ليس ضمن الشبكات الموثوقة Trusted Networks في `AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS`، فمنذ [الإصدار 2026.8](https://docs.goauthentik.io/releases/2026.8/?ref=arabroot.io) يتجاهل authentik هذه الترويسات Headers إذا جاءت من غير شبكة موثوقة، أو slug مختلف، والحل أن تنسخ Callback URL من صفحة الـ Source كما هو.

### رسالة «Error 403: org\_internal»

التطبيق مضبوط على Internal وأنت تدخل بحساب من خارج المؤسسة، وهذا هو السلوك المطلوب، فإذا كان الحساب فعلاً لموظف فتأكد أنه حساب Workspace التابع لمؤسستك لا حساب Google شخصياً بالبريد نفسه، ولاحظ أن قائمة Test users لا علاقة لها بهذا الخطأ، لأنها لا تطبق أصلاً على تطبيق لا يطلب إلا الاسم والبريد.

### ما زال authentik يطلب اسم مستخدم

السياسة مربوطة في موضع خاطئ، أو ترتيبها بعد `default-source-enrollment-if-username`، وموضعها الصحيح هو ربط الـ Stage المسماة `default-source-enrollment-prompt` داخل الـ Flow `default-source-enrollment`، لا الـ Flow نفسه ولا الـ Source.

### رسالة «Username already exists» عند الدخول الأول

هناك حساب محلي بالاسم نفسه، والحل أن تجعل البريد كاملاً اسماً للمستخدم، أو أن تغير User matching mode إلى الربط بالبريد إذا كان الحساب المحلي فعلاً للشخص نفسه.

### لا يظهر الزر في صفحة الدخول

إما أن الـ Source ليس في Selected Sources داخل `default-authentication-identification`، وإما أن الـ Brand يستخدم Flow دخول مخصصاً غير الـ Flow الافتراضي، وفي الحالة الثانية أضف الـ Source إلى الـ Identification Stage في الـ Flow الذي تستخدمه فعلاً.

## الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

- الدخول بحساب Google يوفر على الموظف كلمة مرور جديدة وعليك إعادة تعيينها، ويكفيه في Google عميل OAuth واحد عنوان الـ callback فيه مطابق حرفاً حرفاً لما في authentik.
- اختر Internal إذا كانت لديك Workspace، ومع External لا تحميك قائمة Test users لأن authentik لا يطلب إلا الاسم والبريد، فأي صاحب حساب Google يستطيع الدخول.
- اقصر الدخول على مؤسستك بفحص الحقل `hd` في `oauth_userinfo`، لا بالمعامل `hd` في الرابط ولا بنهاية البريد.
- اترك User matching mode على الربط بمعرف Google الفريد إلا إذا كانت لديك حسابات قائمة وAudience = Internal.
- استخرج اسم المستخدم بسياسة على الـ prompt Stage تعمل مرة واحدة عند التسجيل، واجعل الحسابات الجديدة Internal في مجموعة واحدة.

## سجل التحديثات (Changelog)

- سبتمبر 2026: كتابة الدليل واختباره على [authentik 2026.8.3](https://github.com/goauthentik/authentik/releases/tag/version/2026.8.3?ref=arabroot.io).
- أكتوبر 2026: مراجعة تقنية، صارت فيها سياسة النطاق تفحص الحقل `hd` بدلاً من نهاية البريد كما توصي Google، وصححنا أن وضع Testing لا يقصر الدخول على Test users مع النطاقات الأساسية، وأن authentik يطلب `email` و`profile` فقط، وأضفنا مدة حذف العملاء غير المستخدمين وأثر `AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS` على عنوان الـ callback.