SAML Source POST binding error

[bobbyjenrow]

Describe the bug
I've been attempting to use a third party IdP to act as a source for my Authentik server via SAML.
Using SAML tracer I've been able to verify successful flow from authentik, to the third party sign-on, but on the final SAML post to authentik, a 405 Error is returned.

To Reproduce
Steps to reproduce the behavior:

1. Set up SAML Source with correct SSO URL, Verification Cert, and Redirect Binding
2. Add the source to a stage in default auth flow
3. Attempt to log into the service via third party IdP
4. After successful authentication, the final SAML POST submission with base64 encoded data fails with a 405 Error

Expected behavior
Authentik shouldn't return a 405 Error, since the SAML protocol should expect a POST request.

Authentik Logs on the 405 Response:

Logs
Output of docker-compose logs or kubectl logs respectively

Version and Deployment (please complete the following information):

• authentik version: . 2025.6.3
• Deployment: docker-compose (behind traefik reverse proxy)

Additional context
Add any other context about the problem here.

[loffa]

Hello,

I have tried to set this up today as well using Google Workspace as the SAML source. Got to the same step and fail with a 405 error on the last POST request. I have tested this on the 2025.8.1 version.

Trying a few different things led me to discover that Authntik responds with a 405 on all URL:s that should be 404. I tried removing trailing / and switching to a non-existing slug. All URL:s return 405 if they are invalid, even for GET.

Edit: Also confirmed that the same issue is left after updating to 2025.8.3

[hagaibarel]

Hi,

We're seeing the same issue with version 2025.8.1.

Following this guide https://docs.goauthentik.io/users-sources/sources/social-logins/google/workspace/, the final step while trying to test the login leads to a 405 error on the /source/saml/google/acs/ endpoint.

Inspecting the headers, it seems that the endpoint only allows GET, HEAD, OPTIONS, but the request method is POST

[shsjshentao]

happens the same issue

[maxammann]

Currently evaluating authentik and the Google SAML federation is not working

[maxammann]

The endpoint should handle post though: https://github.com/goauthentik/authentik/blob/version/2025.8.4/authentik/sources/saml/views.py#L147

[loffa]

The endpoint should handle post though: https://github.com/goauthentik/authentik/blob/version/2025.8.4/authentik/sources/saml/views.py#L147

I looked at this code as well but I am not very familiar with Django to make a fix. It seems like the routing might not even come to that part at all. Even when changing to non-existent slug in the URL the result is also 405. Also tried with a GET, still 405.

Perhaps some routing error that is happening here?

[maxammann]

Perhaps some routing error that is happening here?

I agree its odd. The requests actually go through via POST as long as you don't include the data form data encoded payload.

So maybe this is an error showing a failure to parse the SAML request actually.

[maxammann]

Ok I think I got it working!

1. It might be related to TLS errors. I was able to workaround it using a MITM proxy. (I'm just testing locally all right now)
2. check the logs for any obvious errors like wrong ACS urls

[loffa]

@maxammann Did you figure it out in the end? Any instructions how you solved it?

I am running everything behind a SSL terminating reverse proxy. Is the TLS error from something else within Authentik?

[maxammann]

@maxammann Did you figure it out in the end? Any instructions how you solved it?

I am running everything behind a SSL terminating reverse proxy. Is the TLS error from something else within Authentik?

A bit hard to tell, but I can try to reproduce this issue. I was definitely seeing some errors in the server log.

[loffa]

Hi all!

I made some progress on this issue today. I found out what the problem is related to and managed to get a workaround for authentication. However, this involves disabling signature verification on the SAML Source. It also means that no value mapping is working correctly since data can not be read from the SAML POST object.

It seems like the namespaces used in the POST data from Google does not conform to the namespaces defined in NS_MAP, we have several namespaces here and one is samlp. However Google data is put under saml2p. The request validator method validate_signed will raise exceptions for not finding the correct keys, but the exception handler in ACSView does not handle these exceptions so they are sent further up the call tree and results in the 405 response we are seeing. I have not tried any code change to fix this issue but seems like it might be quite easy now when it is narrowed down.

Workaround:
Disable signature vaerification by removing the certificate setting from Signature Verification. The source will skip verifying keys and then authentication works. However data matching does not work since the whole POST data looks "empty" as we use the wrong XML keys.

Tested with 2025.8.4.

[ikob]

Just FYI: The SAML response signature verification fix have been merged main branch, but not released yet (#15626). Also, I am not sure whether it help the namespace issue discussed.

Workaround:
Disable signature vaerification by removing the certificate setting from Signature Verification. The source will skip verifying keys and then authentication works.

[loffa]

Just FYI: The SAML response signature verification fix have been merged main branch, but not released yet (#15626). Also, I am not sure whether it help the namespace issue discussed.

Thanks for letting us know.
However the issue with XML namespaces is not addressed in the linked PR. My test indicate that Googles data with the saml2p namespace can not be parsed at all since it is missing from the namespace map. This was also mentioned in the linked issue #12035, but it is now closed as well. Is that something that needs to be addressed too?