If you ever wanted to use Discourse as your authentication provider - now you can!
Over the last week I’ve written a small service which can be used to act as an OpenID connect/OAuth provider with discourse as a backend.
You can check out the code here:
Note that my primary use case was to authenticate to Nextcloud using Discourse, so it might not be working for your use case.
If something is not working as expected, or it is missing that certain feature to make it work for you, feel free to create an issue in the GitHub repository.
Awesome initiative! I always wanted Discourse to be usable as an OAuth provider, so it can easily be integrated with more tools. Making it an external small service makes a lot of sense too!
I like the sound of this and hope some communities decide to try it out!
I’d love to see OIDC supported by Discourse officially in addition to our bespoke Discourse Connect functionality, so we can offer a turnkey solution to our customers on standard and teams without having to rely on okta or the like.
Distrust is a separate service, so you need to deploy it as such. You can run it in a container as described in the README file. Note that for secure operation, you will also need a reverse proxy handling SSL Termination (I might implement this directly sometime in the future).
אני מקווה לקבל כמה עיניים מומחיות על בעיות שאני נתקל בהן תוך כדי ניסיון להשתמש ב-Discourse כספק SSO.
המטרה שלי: אני מגדיר את Discourse לטפל באימות עבור יישום אחר (LibreChat). אני משתמש בפונקציונליות הסטנדרטית של ספק DiscourseConnect, כאשר שירות הגשר distrust OIDC פועל כלקוח שמתקשר עם Discourse.
הבעיה: זרימת ה-SSO עובדת בצורה מושלמת עד השלב האחרון. המשתמש מופנה כראוי מהאפליקציה שלי ל-Discourse, והוא יכול להתחבר בהצלחה באמצעות פרטי ההתחברות שלו ל-Discourse. עם זאת, לאחר ההתחברות, הוא מופנה חזרה לדף הבית של פורום ה-Discourse שלי (/) במקום ל-return_sso_url שסופק.
היכן אני תקוע (מה שללתי): עבדתי על פתרון הבעיה הזו זמן מה ואישרתי שזו לא שגיאת תצורה פשוטה. שללתי באופן מוחלט את הדברים הבאים:
סודות:סודות ספק ה-Discourse Connect מוגדרים כראוי. אני משתמש בדומיין הפשוט (למשל, auth.my-site.com) ללא כל פרוטוקול, ומפתח הסוד תואם באופן מושלם לזה שבשירות הלקוח שלי.
מדיניות משתמשים: דאגתי ש-must_approve_users יהיה מושבת, ומשתמש הבדיקה שלי הוא מנהל מערכת עם אימייל מאומת במלואו.
תוספים: השבתתי את כל התוספים של צד שלישי שאינם רשמיים ובניתי מחדש את הקונטיינר, אך הבעיה נמשכת.
הראיות המרכזיות: יש לי שני ממצאים מכריעים שמשאירים אותי מבולבל:
ניתוח קובץ HAR: לכדתי את כל זרימת הרשת בקובץ HAR. הוא מראה שהבקשה POST ל-/session לצורך התחברות מצליחה. השרת מגיב מיד עם הפניה מחדש מסוג 302 Found, אך כותרת ה-Location היא באופן עקבי /. זה מוכיח ש-Discourse מבטל בכוונה את הפניית ה-SSO.
יומן Rails ריק: לאחר מכן עקבתי אחר קובץ production.log בתוך הקונטיינר בזמן שניסיתי להתחבר. שום דבר לא נכתב ליומן במהלך תהליך זה. זה אומר לי ש-Discourse לא רואה בזה שגיאה; זו פעולה מכוונת ושקטה.
השאלה שלי: בהתחשב בכך שההתחברות מצליחה, אך ההפניה מחדש שגויה ואין שגיאות ביומנים, איזו מדיניות פנימית של Discourse, בדיקת טרום-טיסה, או הגדרה נסתרת יכולה לגרום לה להתעלם מה-return_sso_url ולהפנות לדף הבית במקום? אני מרגיש שמיציתי את כל ההגדרות הסטנדרטיות.
