Headless social auth for completely separated BE/FE

[lukaszsi]

Hi, firstly, I'd like to thank the creators and maintainers of django-allauth for your outstanding work. The provided example app and documentation have been really helpful, however, as someone not yet deeply familiar with social auth, OAuth2 etc., I find myself quite confused when trying to apply this library to my current project. I believe the documentation could benefit from a bit more context in certain areas, and I am more than willing to contribute towards that once I get past my current initial roadblocks. For now, I have some high-level questions that I hope can help me—and perhaps others—move forward more effectively:

1. Separate Hosting of BE/FE:

   • Context: I am developing a Django + React application where the backend and frontend will be hosted on completely different domains/cloud providers and my auth will be handled by JWT tokens.
   • Question: Is it possible to use django-allauth for headless social auth in such a setup? The "Routing" section in the docs is rather vague on this point. From my experience such architecture is quite popular but is it a deal-breaker for this library to work? I know from the docs that Django auth logic needs to be in-use for social auth and we have this "token strategy" to handle using JWT tokens later on but, after reading all the docs, I still can't answer the main question here.

2. Traefik Proxy in Demo App:

   • Context: The demo app provided is very insightful but the use of Traefik as a proxy has left me puzzled.
   • Question: Is Traefik (or any similar tool) essential for django-allauth to function properly, or it is not necessary for the library to work? If it's not, why was it added then? This may also tie into my first question about domain separation I guess.

Thanks in advance for your insights and clarifications!

[pennersr]

There are 2 ways of using the headless functionality: "browser" and "app". The "browser" strategy is dependent on cookies, which is obviously not going to work when backend and frontend are completely separated domain wise. The "app" strategy works fine when backend and frontend are separated, including social authentication. You are on your own though security wise. Just recently I saw an interesting thread coming by on this topic, e.g. see https://www.reddit.com/r/django/comments/1dpi620/comment/lahiwlt/

So no, it's not a dealbreaker:

• Use "app".
• Pass along the X-Session-Token until the user becomes authenticated.
• Plug in your own token strategy that emits your JWT access token.
• Once authenticated, allauth will expose that JWT token and you can continue from there.

As for Traefik, if you are running both backend and frontend on one and the same domain, you will need to route some paths to the frontend, some to the backend. Traefik is just used for development purposes to show that aspect. You can do without during development, but then you'll have to do some port hopping as the frontend is running on e.g. 3000 and the backend on 8000. So, if both on the same domain is your setup, I prefer to have the local development environment match production, hence the use of Traefik.