First, django-allauth supports an impressive list of providers. FusionAuth can support most of them using our generic OIDC connector, but kudos to the django-allauth team! If you are sure you only are building one django app, it's a good choice (and way better than rolling your own auth lib--please don't do that).

I'm not super familiar with django-allauth, but I did a bit of research. I think the reasons to use FusionAuth rather than django-allauth are:

centralized user management and control, even if you use a social provider. This scales to multiple applications within one tenant (so a django app and an open source forum app like nodebb can share a userbase; each user has the same username/email and password for each app) and multiple tenants (so you can have django app A and django app B totally separated, with different usernames/emails and passwords, if you're whitelabelling your app) ability to integrate with other auth providers using non OAuth protocols, like SAML FA is a single app, as opposed to a set of extensions you need to find, merge together, and keep in sync. You just drop it in and it works. additional features that you might not know you need until you need them (and have to build or evaluate/integrate a different library): passwordless consents family grouping webhooks for integration on user changes user actions groups jwt generation DAU/MAU reporting 2fa (I saw a 2fa plugin for this, but it was supported version 0.25 and django-allauth is at 0.42)

In short, FA is a full user management system, as opposed to an authentication and authorization plugin like django-allauth.

Hiya,

I got an answer for you about sunset provisions.

We have discussed source code escrow options with clients in the past. We can also offer a source code release clause (in the event FusionAuth goes out of business). However, these are only options if you are on an Enterprise plan with a custom contract.

Hope that helps you make the right decision for your application(s).