AWS Cognito: إدارة المستخدمين والمصادقة
يوفر AWS Cognito حلاً موثوقاً وقابلاً للتوسع لإدارة المستخدمين والمصادقة لتطبيقات الويب والجوال، بدون الحاجة لتشغيل بنية خلفية هوية خاصة. الخدمة تدمج مقدمي هوية خارجيين وتوفر رموز API معيارية. إضافة إلى ذلك، فهو يتيح تبديل رموز الهوية مقابل بيانات اعتماد AWS مؤقتة للوصول المباشر إلى خدمات AWS مثل S3 وDynamoDB.
Quelle: عرض مخصص
أساسيات AWS Cognito
يتكون AWS Cognito من مكوّنين أساسيين: User Pools و Identity Pools.
User Pools هي دليل مستخدم و OpenID-Connect-kompatibler Identity Provider. إنها تتحقق من هوية المستخدم، وتصدر رموز الهوية ورموز الوصول ورموز التحديث، وتدمج مقدمي هوية اجتماعية أو مؤسسية عبر OIDC أو SAML.
Identity Pools (المعروفة أيضاً بالهويات الموحدة) توفر بناءً على هذه الهويات kurzlebige AWS-Credentials. هذا ممكن أيضاً للضيوف الذين لم يقوموا بتسجيل الدخول بعد.
صفحة تسجيل الدخول المدارة، التي كانت تعرف سابقاً بـ „Hosted UI“ واليوم تُسمّى „Managed Login“، تتيح
standardkonforme OAuth-Endpunkte جاهزة، بما في ذلك
/oauth2/authorize, /oauth2/token, /logout وكشف OIDC- OIDC Discovery- و JWKS-Ressourcen.
بالنسبة لتطبيقات الصفحات المفردة (SPAs)، فإن
Authorization-Code-Flow mit PKCE لأنه ذو أهمية مركزية، لأنه يمنع إساءة استخدام الرموز التي يتم اعتراضها.
الرموز المصدرة هي JSON Web Tokens (JWTs). تنقل رموز الوصول نطاقات ومجموعات للمصادقة على واجهات API، بينما تحتوي رموز الهوية على معلومات الملف الشخصي. يمكن التحقق من توقيعات هذه الرموز مقابل عنوان JWKS للمجموعة المعنية.
الحالة الراهنة والوظائف
يمكن ضبط فترات صلاحية الرموز بدقة لكل عميل تطبيق. يمكن أن تكون فترات الوصول ورموز الهوية بين 5 Minuten und 1 Tag يمكن ضبطها. تمتلك رموز التحديث صلاحية افتراضية قدرها 30 يوماً، والتي يمكن تعديلها بين 60 Minuten und 10 Jahren يمكن تخصيصها.
صفحات تسجيل الدخول المدارة تدعم PKCE standardmäßig. الخروج Logout-Endpunkt ينهي جلسة المتصفح ويعيد التوجيه إلى عناوين تسجيل خروج مُكوَّنة.
Quelle: aws.amazon.com
نظرة عامة على الوظائف الأساسية لـ Amazon Cognito.
يمكن إعدادها لعرض علامة تجارية مخصصة واستخدام نطاقات خاصة. Custom Domain mit einem ACM-Zertifikat يمكن إعدادها (شهادة في us-east-1 مطلوبة). بعدها يتم تسجيل الدخول عبر النطاق الفرعي الخاص بك.
يمكن حماية APIs إما مباشرة عند API Gateway باستخدام JWT-Authorizer محمي، حيث يقبلها Cognito كجهة إصدار OIDC، أو عبر موفِّر تفويض خاص (Lambda-Authorizer).
هذه adaptive/risikobasierte Anmeldung („Threat Protection“) يمكنه تصنيف محاولات تسجيل الدخول المشبوهة، وفرض المصادقة متعددة العوامل (MFA)، أو حجب الوصول.
للتطبيقات متعددة المستأجرين توثق AWS نماذج مختلفة، بدءاً من نموذج واحد يشمل العزل عبر المجموعات/الأدوار ونطاقات. Single-Pool-Ansatz bis hin zu einem Pool pro Tenant, يشمل العزل عبر المجموعات/الأدوار ونطاقات.
يتم دمجها في تطبيقات Next.js من خلال Cognito-Provider von NextAuth بشكل مبسَّط. تُدار الجلسات عبر JWTs/الكوكيز، وتُحمي Edge-Middleware المسارات.
الخلفيات والدوافع
التطبيقات الحديثة تحتاج طبقة هوية مركزية تدعم معايير الصناعة مثل OIDC/OAuth2/SAML يدعمها، ويعالج المخاطر عبر MFA والمصادقة التكيفية، وفي الوقت نفسه يتيح دمج مزودي الهوية الخاصين. بالنسبة لـ SPAs فإن PKCE unverzichtbar, حيث لا يمكن حفظ أسرار العميل بأمان في المتصفح؛ يطبق Cognito PKCE بشكل كامل.
على جانب API، يكون الوصول المباشر JWT-Abgleich am API Gateway جذاب. يوفر زمن استجابة منخفض، فصلاً واضحاً بين المصادقة (AuthN) والتفويض (AuthZ)، ويتجنب رحلة إضافية ذهاباً وإياباً إلى مخزن المستخدم.
الامتثال ومكان إقامة البيانات هي جوانب مهمة أخرى. تخزن User Pools بيانات الملف الشخصي إقليمياً. يمكن لميزات اختيارية مثل Pinpoint-Analytics إرسال البيانات إلى مناطق أخرى، وهو أمر ذو صلة بفرق EU/CH و besondere Beachtung erfordert.
Quelle: يوتيوب
يعرض هذا الفيديو SAML-Föderation mit Cognito, ما هو مفيد لفهم سيناريوهات قائمة على IdP وتسجيل خروج أحادي بشكل بصري.
التطبيق العملي والتوصيات
من يقوم بتطوير SPA أو تطبيق Next.js يجب أن يختار Authorization Code Flow mit PKCE يجب حفظ الرموز في httpOnly-Cookies من جانب الخادم أو استخدام آلية الجلسة الخاصة بإطار العمل. يجب دائماً التحقق من JWTs مقابل عنوان JWKS للمجموعة المعنية. JWKS-Endpunkt des Pools يتم.
Quelle: economize.cloud
تدفق المصادقة النموذجي مع AWS Cognito.
ينبغي أن تتحقق واجهات API من Scopes وتستخدم JWT-Authorizer لاستخدامها لفصل المصادقة والتفويض والحفاظ على زمن استجابة منخفض.
للAplications متعددة المستأجرين، من المستحسن البدء بنموذج واحد، Single-Pool-Ansatz بالبدء بنموذج واحد، مع إضافة سمات المستأجر أو مجالات. في حال وجود متطلبات عزل صارمة، يمكن التفكير في وجود مجموعة لكل مستأجر.
في قسم العمليات من المستحسن CloudTrail und CloudWatch-Metriken تمكينها، ومراقبة الحصص ونماذج تسجيل الدخول، واستخدام اختياري للـ Threat Protection استخدامه.
فيما يخص الامتثال يجب فحص تدفقات البيانات الإقليمية (مثلاً عبر التحليلات) وتوثيقها لفرق الاتحاد الأوروبي/سويسرا، لا سيما مع مراعاة ال regionalen Datenüberlegungen.
Quelle: يوتيوب
هذا الشرح يساعد في فهم Authorization-Code-Flow mit PKCE من النهاية إلى النهاية.
الأسئلة والتحديات المفتوحة
تصميم TTL الرمز وتدويرها يجب أن يوازن بعناية بين تجربة المستخدم ومستوى الأمان لإيجاد توازن، دون إرهاق التطبيقات بالتحديث المستمر. توصي AWS باستخدام الرموز لمدة نحو 75 Prozent ihrer Lebenszeit لاستخدامها ثم تجديدها.
يطرح السؤال إلى أي مدى يكفي عزل المستأجرين عبر المجموعات/Scopes قبل أن يصبح تقسيم المجموعة ضرورياً من الناحية التنظيمية والتكاليف. تشرح AWS كلا الخيارين، لكن العتبات القابلة للاعتماد هي anwendungsabhängig.
Quelle: aws.amazon.com
تكامل Cognito مع مقدمي الهوية الخارجيين وخدمات AWS.
أي بيانات يجوز لها وفقاً لقواعد الامتثال المختلفة مغادرة المنطقة في حال تفعيل ميزات اختيارية مثل Pinpoint؟ هنا هي regionalen Hinweise يجب فحصها وتوثيق موافقات الاختيار (Opt-ins).
إتساق تسجيل الخروج الأحادي عبر جميع IdPs المرتبطة يمثل تحدياً آخر. بالنسبة لـ SAML هناك SLO-Unterstützung, إلا أن تفاصيل التنفيذ تختلف باختلاف IdP.
الخلاصة: يقدم AWS Cognito جوهر مصادقة قوي قائم على المعايير مع نقاط امتداد واضحة: تسجيل دخول مُدار مع PKCE، تحقق JWT نظيف، وت federation اختيارية إلى IdPs اجتماعية أو مؤسسية. عملياً، من الحاسم اختيار التدفق المناسب للتطبيق، وتقييد الرموز بشكل واعٍ، وتفويض طبقة API بشكل صارم عبر النطاقات. عند التخطيط لهندسة متعددة المستأجرين، يجب اتخاذ قرارات مبكرة حول حدود العزل ومقاييس التشغيل. اللبنات موجودة، والقرار التصميمي يعود للمستخدم.