Yes, we are using KeyCloak and use Azure AD for federation in behind it. It’s correctly bootstrapping the email, so it must do some kind of mapping just like the one you mention.
We have a fix. We were using the v1.0 version of the endpoint. When we switch to the v2.0, it works and we get the email just fine. Thanks for all your help @david, talking it through helps us triage the issue.
Glad to hear it!
Would you be able to describe how to tell whether you’re using v1 or v2 in the azure portal? Then we can add a note to the instructions above so it doesn’t catch anyone else!
Yep, adding /v2.0/ to the metadata document url.
https://login.microsoftonline.com/replace-with-tenant-id/v2.0/.well-known/openid-configuration
Perfect, thanks. I’ve added a note to the OP
مرحبًا، أنا أواجه مشكلة مشابهة جدًا للمشكلة الأصلية المذكورة هنا. أقوم بالمصادقة على NHS.net، والتي تعمل في الخلفية عبر Active Directory وعلى الأرجح مُقدَّمة عبر Azure. أستخدم إضافة OIDC وأحصل على الخطأ التالي:
(oidc) Authentication failure! invalid_credentials: OAuth2::Error,
(ينتهي الخطأ بفاصلة ولا يحتوي على بيانات إضافية، على عكس خطأ المنشئ الأصلي)
لقد حاولت تغيير إعدادات نطاق التفويض ونطاق الرمز إلى openid email profile (وهذه مدعومة في نقطة نهاية OIDC وفقًا لبيانات عنوان URL للإعدادات)
لا يزال الخطأ نفسه يظهر في واجهة المستخدم: ‘عذرًا، حدث خطأ أثناء تفويض حسابك. يرجى المحاولة مجددًا.’
يبدو أنني لا أحصل على أي بيانات من JWT. لذا فإن المشكلة ليست تمامًا مثل مشكلة ‘حقل البريد الإلكتروني المفقود’، لكنها بدأت بنفس الخطأ. الموقع الوحيد الآخر على Meta الذي وجدت فيه هذا الخطأ (والذي يبدو ذا صلة) هو SSL Error during OAuth2. اتضح أن هذه المشكلة تتعلق بمشكلة في SSL (ومن المثير للاهتمام أن شهادة NHS.net تحتوي على هذه المشكلة، وقد أبلغت عنها). لكن بعد تثبيت حل SSL، اختفت أخطاء Faraday المتعلقة بـ SSL. ومع ذلك، لا يزال يبدو أن جزءًا ما من تدفق OpenID Connect معطل.
هل هناك أي اقتراحات للخطوات التالية في تصحيح هذه المشكلة؟