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.

[pennersr]

The ACSView is the view handling the redirect from the IdP to the RP/SP. The headless endpoint initiates the redirect from the RP/SP to the IdP:

https://docs.allauth.org/en/dev/headless/openapi-specification/#tag/Authentication:-Providers/paths/~1_allauth~1browser~1v1~1auth~1provider~1redirect/post

So the flow is:

1. You initiate the redirect by POST'ing to the headless redirect endpoint, including a callback_url pointing to your frontend.
2. That endpoint redirects to the IdP.
3. After authorizing over at the IdP, you are redirected back to the callback URL of the IdP. For Google, that is /accounts/google/login/callback, for SAML that is the URL matching the ACSView.
4. That callback code processes the login, and redirects back to your frontend (callback_url).

[pennersr]

Btw:

It looks like in the beta...
... the headless implementation is so new and presumably still a WIP.

The headless implementation is out of beta, it's no longer a WIP. It is definitely new though...

[banagale]

After authorizing over at the IdP, you are redirected back to the callback URL of the IdP...for SAML that is the URL matching the ACSView.

Do you mean the IdP to redirects to the "backend" or template-view-base url created by allauth.socialaccount.providers.saml.urls by the RP?

Is this URL set on the IdP's SSO configuration? Then, the callback_url bringing them home to the RP's frontend rides through all of this?

We use a different subdomain for backend requests.

It seems like for a brief moment the user would see this domain before being redirected to the frontend domain but ultimately be authenticated correctly. Does that sound correct?

In summary, IIUC, the headless version still uses the existing allauth urls to process and redirect the user. So, the auth process does require these to be surfaced even if only briefly.

I had, I think been expecting "it all to happen in the frontend" but that is perhaps too complex and unnecessary.

The headless implementation is out of beta, it's no longer a WIP. It is definitely new though...

Got it. Its awesome you've delivered it, and I'd much prefer to use it than rolling my own here.

Here's a screen cap of that config on today's Google Admin page for Service Provider Details, presumably I'd want the backend ACSView under ACS URL.

\

[pennersr]

The IdP is redirecting to the backend, yes. That is unavoidable, as for many providers a POST is involved which cannot be handled nor forwarded from the frontend side.

[banagale]

I see. Thank you for that, it seems obvious in retrospect.

Once I have this up and working, I can see about crafting some changes to the docs that outline the process in more detail.

[banagale]

@pennersr How does the backend redirect the SAML-authenticated user to the frontend?

For example, there's the get_login_redirect_url. I want to redirect the user there with the valid django session token so they can be recognized and logged in on the frontend.

[pennersr]

The whole flow is initiated by this call https://docs.allauth.org/en/latest/headless/openapi-specification/#tag/Authentication:-Providers/paths/~1_allauth~1browser~1v1~1auth~1provider~1redirect/post -- here, the frontend has the opportunity to hand over a callback_url so that the frontend can boot back up after the handshake with the IdP on the backend is complete.