<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>News on django-allauth</title><link>https://allauth.org/news/</link><description>Recent content in News on django-allauth</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Thu, 13 Aug 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://allauth.org/news/rss.xml" rel="self" type="application/rss+xml"/><item><title>django-allauth 65.19.1 released</title><link>https://allauth.org/news/2026/08/django-allauth-65.19.1-released/</link><pubDate>Thu, 13 Aug 2026 00:00:00 +0000</pubDate><guid>https://allauth.org/news/2026/08/django-allauth-65.19.1-released/</guid><description>Fixes IdP: Fixed an incorrect URL reverse in the OpenID Connect authorization template. It silently resolved to an empty form action (posting back to the same URL), so the flow kept working regardless. IdP: Redirectable errors from the authorization endpoint were not delivered to clients registered with an app native (non-http(s)) redirect_uri.</description></item><item><title>django-allauth 65.19.0 released</title><link>https://allauth.org/news/2026/08/django-allauth-65.19.0-released/</link><pubDate>Thu, 06 Aug 2026 00:00:00 +0000</pubDate><guid>https://allauth.org/news/2026/08/django-allauth-65.19.0-released/</guid><description>Noteworthy changes Officially support Django 6.1. IdP: Added support for Client ID Metadata Document (CIMD). IdP: Added IDP_OIDC_REFRESH_TOKEN_EXPIRES_IN, allowing refresh tokens to expire. Combined with IDP_OIDC_ROTATE_REFRESH_TOKEN, this results in a sliding (inactivity) window. Defaults to None (no expiry), preserving the previous behavior.</description></item><item><title>django-allauth 65.18.0 released</title><link>https://allauth.org/news/2026/05/django-allauth-65.18.0-released/</link><pubDate>Fri, 29 May 2026 00:00:00 +0000</pubDate><guid>https://allauth.org/news/2026/05/django-allauth-65.18.0-released/</guid><description>Noteworthy changes The password2 (password confirmation) field on the set/change/reset password forms now carries autocomplete=&amp;quot;new-password&amp;quot;, matching password1. This allows browser and password manager &amp;quot;suggest strong password&amp;quot; features to fill both fields as a pair. IdP: Added support for Dynamic Client Registration.</description></item><item><title>Showcasing allauth IdP: build an MCP server</title><link>https://allauth.org/news/2026/05/idp-demo-mcp-server/</link><pubDate>Fri, 29 May 2026 00:00:00 +0000</pubDate><guid>https://allauth.org/news/2026/05/idp-demo-mcp-server/</guid><description>Introduction The allauth.idp (Identity Provider) package was introduced last year, yet it remains relatively unknown. What better way to put it on people&amp;#39;s radar than building a demo? Given all the buzz around LLMs, let&amp;#39;s showcase its capabilities by building an MCP server that authenticates via OIDC, using nothing but plain Django and django-allauth.</description></item><item><title>django-allauth 65.17.0 released</title><link>https://allauth.org/news/2026/05/django-allauth-65.17.0-released/</link><pubDate>Wed, 20 May 2026 00:00:00 +0000</pubDate><guid>https://allauth.org/news/2026/05/django-allauth-65.17.0-released/</guid><description>Noteworthy changes Added new socialaccount provider: Klaviyo. Rate limiting now truncates IPv6 addresses to their network prefix (default /64) to prevent bypass via address rotation. Configurable via ALLAUTH_RATE_LIMIT_IPV6_PREFIX. Added authenticate_by_email hook to DefaultSocialAccountAdapter, allowing customization of user lookup and email matching during social login.</description></item><item><title>django-allauth 65.16.1 released</title><link>https://allauth.org/news/2026/04/django-allauth-65.16.1-released/</link><pubDate>Fri, 17 Apr 2026 00:00:00 +0000</pubDate><guid>https://allauth.org/news/2026/04/django-allauth-65.16.1-released/</guid><description>Security notice The state parameter is a critical part of the OAuth2 handshake, used to prevent CSRF attacks. The Edx, AngelList and Questrade providers were originally added without state support, as these providers did not support it at the time.</description></item><item><title>django-allauth 65.16.0 released</title><link>https://allauth.org/news/2026/04/django-allauth-65.16.0-released/</link><pubDate>Mon, 13 Apr 2026 00:00:00 +0000</pubDate><guid>https://allauth.org/news/2026/04/django-allauth-65.16.0-released/</guid><description> Noteworthy changes MFA: You can now configure recovery codes to be only shown once (MFA_RECOVERY_CODES_SHOW_ONCE = True). New signals for audit trail purposes: login_code_rejected, password_reset_code_rejected, email_verification_code_rejected (in allauth.account.signals) and authentication_failed (in allauth.mfa.signals).</description></item><item><title>django-allauth 65.15.1 released</title><link>https://allauth.org/news/2026/04/django-allauth-65.15.1-released/</link><pubDate>Thu, 02 Apr 2026 00:00:00 +0000</pubDate><guid>https://allauth.org/news/2026/04/django-allauth-65.15.1-released/</guid><description>Fixes The context data for the various entrance views was inconsistent, e.g. some where missing site or login_url. Ensured all entrance views are now handed over the same base context. MFA: accessing the WebAuthn login view while already being authenticated resulted in a 500, fixed.</description></item><item><title>django-allauth 65.15.0 released</title><link>https://allauth.org/news/2026/03/django-allauth-65.15.0-released/</link><pubDate>Mon, 09 Mar 2026 00:00:00 +0000</pubDate><guid>https://allauth.org/news/2026/03/django-allauth-65.15.0-released/</guid><description>Noteworthy changes All user facing codes (e.g. those that the user needs to manually input over at password reset, email/phone verification, login code, OIDC device codes) now follow the recommendations over at RFC 8628, Section 6.1. It uses dashed codes, such as &amp;quot;WDJB-MJHT&amp;quot;, by default.</description></item><item><title>django-allauth 65.14.2 released</title><link>https://allauth.org/news/2026/02/django-allauth-65.14.2-released/</link><pubDate>Fri, 13 Feb 2026 00:00:00 +0000</pubDate><guid>https://allauth.org/news/2026/02/django-allauth-65.14.2-released/</guid><description>Security notice Rate limiting and IP address detection: as Django applications cannot reliably determine client IP addresses out of the box, you must override get_client_ip() to match your deployment architecture. If you omitted to do so, the default implementation trusted X-Forwarded-For, which can be spoofed to bypass rate limits.</description></item><item><title>django-allauth 65.14.3 released</title><link>https://allauth.org/news/2026/02/django-allauth-65.14.3-released/</link><pubDate>Fri, 13 Feb 2026 00:00:00 +0000</pubDate><guid>https://allauth.org/news/2026/02/django-allauth-65.14.3-released/</guid><description> Fixes Version 65.14.2 was not compatible with Python 3.8/3.9 due to use of an unsupported typing construct, fixed.</description></item><item><title>django-allauth 65.14.1 released</title><link>https://allauth.org/news/2026/02/django-allauth-65.14.1-released/</link><pubDate>Sat, 07 Feb 2026 00:00:00 +0000</pubDate><guid>https://allauth.org/news/2026/02/django-allauth-65.14.1-released/</guid><description>Fixes When using ACCOUNT_CHANGE_EMAIL = True, if the user initiating the change email process had no verified email address, user.email would still reflect the old email address while the verification process was pending. Security notice SAML: When IdP initiated SSO was enabled (it is by default disabled), any URL found in the SAML RelayState parameter would be used to redirect to, potentially redirecting the authenticated user to a wrong site.</description></item><item><title>django-allauth 65.14.0 released</title><link>https://allauth.org/news/2026/01/django-allauth-65.14.0-released/</link><pubDate>Sat, 17 Jan 2026 00:00:00 +0000</pubDate><guid>https://allauth.org/news/2026/01/django-allauth-65.14.0-released/</guid><description>Noteworthy changes Steam: the provider now supports initiating headless logins per redirect. Shopify: if email_verified is present in the user payload, it will be used to mark the email address retrieved as verified accordingly. IdP: added support for JWT based access tokens (see IDP_OIDC_ACCESS_TOKEN_FORMAT).</description></item></channel></rss>