Comparing ACSView / FinishACSView and Headless SSO endpoint

[banagale]

It looks like in the beta that the SSO redirection is handled in a single endpoint.

I don't understand how the old way, the ACSView -> FinishACSView views are now represented in the new headless version.

I have been able to prove our intended SSO/SAML via google config works using Allauth's traditional template view-based SocialApp workflow.

I could not tell if the headless SSO endpoint covers our use case. It seemed like replicating the allauth socialapp (saml) old django view behavior via the frontend might be "safer."

Because we need headless auth via allauth's SSO, (SAML specifically) as soon as possible and the headless implementation is so new and presumably still a WIP.

Here's a workflow that would be a "headless" use of allauth sso/saml using old view code:

1. After the user successfully authenticates at the 3rd party (Google in this case) Google POSTs to a frontend endpoint ie /auth/acs-sso/
2. Data from G is POST'd by the frontend to an API endpoint that is basically ACSView.
3. A successful response from that endpoint redirects to another react page /auth/acs-sso/finish that completes the social login and returns the now valid auth session
4. The user is redirected to the dashboard carrying the session cookie in the browser and all is well.

However, I haven't been able to make this work yet.

I could use some feedback on if and how the new headless socialapp webhook works in one step. Or if it doesn't handle the SSO/Saml use case, if the workflow above makes any sense at all as a workaround.

Before the headless project was announced I had personally implemented headless auth endpoints for login, logout, password reset, invite workflows, etc. So, I've pulled off some of this before.

And I was surprised and delighted about the grant and @pennersr efforts to extend allauth work for so many more use cases and make much of that work unnecessary for others.