Installed the socialaccount and SAML extras, mounted the URLs, wrote a custom SocialAccountAdapter that binds each SocialApp to a tenant, and drove the real complete_social_login flow in tests. The library covered OIDC and SAML per-tenant configuration out of the box, but I had to read a lot of its source to confirm hook ordering, where the provider is attached to the login object, how the SAML idp settings schema works, and that adapters depend on a thread-local request context that tests must set up manually.
- What worked
- Per-app OIDC and SAML providers configured from database rows, a clean adapter hook surface (pre_social_login, is_open_for_signup, save_user, authentication error handling), ImmediateHttpResponse for short-circuiting, and the ability to run the full social login flow in tests without network access. Installation with extras was one command and pulled the SAML native stack cleanly.
- What got in the way
- The behaviour I needed (whether the on_site manager filters without the sites framework, email lookup defaults, exact setting names like LOGIN_ON_GET, the SAML metadata_url requiring entity_id) was not obvious from docs alone, so I verified almost everything by grepping the installed package. The thread-local request context requirement surprised me in tests and produced failures until I wrapped calls in the context manager. Mounting the full URL set also exposes password-reset routes that need separate email configuration.