ID Token أم Access Token: خطأ شائع في تطبيقات تسجيل الدخول

في أنظمة OAuth 2.0 و OpenID Connect قد يحصل التطبيق على أكثر من Token، وتشابه شكلها—خصوصًا عندما تكون JWT— يجعل بعض المطورين يعاملونها كأنها الشيء نفسه. لكنها تخدم أغراضًا مختلفة. ID Token يخبر Client عن حدث المصادقة وهوية المستخدم ضمن OpenID Connect، بينما Access Token هو credential مخصص للوصول إلى Resource Server/API ضمن Scope محدد. الخلط بينهما يضع الثقة في مكان غير صحيح.

ID Token موجهة لل Client

ID Token تحتوي Claims مثل issuer و subject و audience وربما auth_time وغيرها. ال ـClient يتحقق منها ليعرف أن مزود الهوية صادق على المستخدم. Audience يجب أن تتضمن ال ـClient المقصود. لا ينبغي إرسال ID Token عشوائيًا إلى APIs باعتبارها تصريح وصول.

Access Token موجهة لل Resource Server

API تستقبل Access Token وتتحقق من صلاحيتها و scope/audience حسب تصميم المزود. ال ـClient لا يجب أن يفترض شكلها الداخلي؛ قد تكون JWT أو opaque token. ما يهم هو أنها تصريح للوصول إلى مورد، لا بطاقة هوية للمستخدم.

لا تستخدم Claims بلا تحقق

فك JWT Base64 لا يعني التحقق منها. يجب التحقق من signature و issuer و audience و exp وغيرها وفق المكتبة والبروتوكول. كذلك لا تثق في email كمعرف ثابت إذا كان provider يحدد subject مختلفًا.

ماذا عن Refresh Token؟

Refresh Token تستخدم للحصول على Access Tokens جديدة وغالبًا أطول حساسية من Access Token نفسها. لا ترسلها إلى Resource APIs، وخزنها بطريقة آمنة وطبق rotation/revocation عندما يدعم المزود ذلك.

صمم الحدود بين Frontend و Backend

في تطبيقات الويب، تجنب توزيع Tokens أكثر مما يلزم. Backend يمكن أن يحتفظ ببعض الاعتمادات ويمنح Browser Session مناسبة بدل كشف Refresh Token للواجهة. القرار يعتمد على architecture، لكن المبدأ هو أقل exposure ممكن.

اختبر Audience الخاطئة عمدًا

ضمن اختبارات الأمان، أرسل Access Token مخصصة لخدمة A إلى خدمة B وتأكد أنها تُرفض، وافعل الشيء نفسه مع ID Token في endpoint يتوقع Access Token. هذه الاختبارات السلبية تكشف APIs تقبل أي JWT موقعة من نفس issuer بلا تحقق كافٍ من aud أو scope. التحقق الصحيح يجب أن يثبت أن Token صالحة لهذا المورد تحديدًا، لا أنها تبدو أصلية فقط.