Request to Sharepoint sign-in endpoint ?wa=wsignin1.0 returns 403

Question

Request to Sharepoint sign-in endpoint ?wa=wsignin1.0 returns 403

Paul Graham1 150

SAML authentication flow for our ERP integration with SharePoint stopped working for multiple customers.

In the final step of the authentication, the POST request is sent with the BinarySecurityToken in the body to the address below. Instead of returning the FedAuth authentication cookie, it responds with the HTTP code 403 - Forbidden.

https://[YourDomain].sharepoint.com/_forms/default.aspx?wa=wsignin1.0

To clarify: This is not a new development or new installation. This is something that has been working for a long time and for many customers, and recently, it stopped.

0 comments

8 answers

Your answer

Answer 1

rob.h 10

LegacyAuthProtocolsEnabled is not sufficient. You need the setting AllowLegacyBrowserAuthProtocolsEnabledSetting. Please note that the spelling in the documentation is incorrect (the prefix “Allow” and the suffix “Setting” are missing in the documentation).

This worked for us:

Set-SPOTenant -AllowLegacyBrowserAuthProtocolsEnabledSetting $true

This may not work after October 15th 2025, see https://cdm.iamcloud.info/docs/Content/RevertChange.htm

Related link: https://mc.merill.net/message/MC1097272

Raúl Ramírez 0 Reputation points

2025-09-16T08:33:11.2433333+00:00

I tried it but still doesn't work for me. I keep getting the 403 error and no cookies. I have those params changed to true:
LegacyAuthProtocolsEnabled : True

LegacyBrowserAuthProtocolsEnabled : True

AllowLegacyBrowserAuthProtocolsEnabledSetting : True EDIT: After 20 minutes, it worked. It seems you have to wait a bit after making those changes, but it finally works.
David VanSickle 5 Reputation points

2025-09-16T11:18:36.91+00:00

You need to open a premier, unified support ticket if you need a temporary extension. I referenced our support case and someone else's in the thread. You will not get past this without reaching out to Microsoft.
SColley 20 Reputation points

2025-09-16T14:00:21.1966667+00:00

Worked immediately on my tenant

Answer 2

Adi Roiban 25

We are not talking about Basic Authentication

This is SAML Claims-Based authentication with the Federation Authentication (FedAuth) cookie

With the user based authentication model, we get fine grained permissions for SharePoint Files

With OAuth2 Application ID, you only have generic site-level permisisons.

0 comments

Answer 3

Jake Novak 30

Given the length of time this was unavailable, we were forced to update our code to use a different authentication method.

To their credit, Microsoft Support did finally respond to our case number and reversed the change on our tenant (with warnings that it would become unavailable again around October). The former code we had been using for over a decade began working again at that time.

SColley 20 Reputation points

2025-08-21T12:09:53.74+00:00

Hi Jake.

Which authentication method did you go to? Can you point me in the right direction.

My code has only been working for 9 years and now suddenly stopped!

Cheers

Steve
David VanSickle 5 Reputation points

2025-08-21T13:29:01.56+00:00

I hope we can get the same exception! Did you open a Sev A ?
Jake Novak 30 Reputation points

2025-08-21T13:36:12.1966667+00:00

@David - Yes; it was a Sev A ticket, and we had a lot of intervention from our account mgr.

@SColley - Our temporary fix was the least invasive code option, Azure ACS, but that will be turned off in April. Long term we will likely be migrating to Graph.
David VanSickle 5 Reputation points

2025-08-27T21:49:48.13+00:00

@Jake Novak can you please share the Sev A ticket #, if you need to send it to me privately, my email address is ******@fcsamerica.com
David VanSickle 5 Reputation points

2025-08-27T21:50:38.91+00:00

first.lastname Jake, sorry, the forum obfuscated it.
David VanSickle 5 Reputation points

2025-08-29T12:22:44.3933333+00:00

With a significant amount of work, we were finally able to get an extension. "Please be informed that the security enforcement applied to your tenant has been reversed, this is valid until Oct 15th, 2025." The support case number was TrackingID#2508210040005205. Thanks to Jake Novak, the Sev A case you opened made all the difference! Happy Friday all!
Corey White 0 Reputation points

2025-09-08T17:11:27.1366667+00:00

@David VanSickle Looks like our tenant ran into the same issue starting Friday. Did you turn in your ticket through Direct support? I am trying to figure out the quickest way to get our's turned back on.
David VanSickle 5 Reputation points

2025-09-08T17:14:49.81+00:00

We did, but honestly, it was a nightmare. If you have access to a unified support agreement and can open a Sev A, that is the best way. If you do that reference this case number #2508190040009024 and send Jake Novak a big thank you!
Raúl Ramírez 0 Reputation points

2025-09-19T09:01:11.1266667+00:00

@Jake Novak Could you please help me to fix the problem using Azure ACS?

I have a connector using Graph API, but it's very slow due to the API calls being slow and it doesn't let you do a lot of requests in a short time.

If you need to send it to me privately, my email address is ******@driving01.com (without accents).

Thanks in advance.

Answer 4

Wiese 25

we migrated to token-based authentication using Azure AD.

Here’s how it works now:

Token-based authentication

Instead of sending the FedAuth cookie, we send an access token in the Authorization header of every HTTP request to SharePoint.

App-based access

The access token is obtained from an Azure AD app registration. This means that access is granted to the application itself (app-based authentication), rather than to a specific user.

JWT signing requirement

To request an access token, the client must present a signed JWT. The JWT is signed using the private key of a certificate. The public certificate must be uploaded to the Azure AD app registration so that Azure AD can validate the signature.

This setup removes dependency on user context and enables secure, app-only access to SharePoint resources.

David VanSickle 5 Reputation points

2025-08-21T13:25:08.0933333+00:00

Here's what we were told by Microsoft in July, no mention of specific protocol blocks above the tenant level. We specifically asked about the impact on a legacy Infoburst deployment. Yesterday, we began getting failures. I'm hoping there's a case for an exception group.

Informed you that the policy described is part of Microsoft’s Secure by Default initiative. It includes the following updates:

Blocking of legacy authentication protocols (e.g., RPS and Basic Auth)

Requirement to use modern authentication methods such as OAuth

Impact on services including Exchange Online, SharePoint Online, Microsoft Teams, and Microsoft Entra

However, this policy primarily affects tenants that manage Multi-Factor Authentication (MFA) using Security Defaults.

In your case, since your tenant manages MFA through Conditional Access Policies, this change will not impact your users—unless you have explicitly configured a policy that enforces these new settings.

In summary, because you are managing authentication through Conditional Access, you retain full control over how these policies are applied in your environment.
SColley 20 Reputation points

2025-08-22T01:22:52.9933333+00:00

Please let us know if that is the case. I assumed as Microsoft still offers app passwords when mfa is enforced (in fact enforced seems necessary to active it) that this would still allow FedAuth and rtFa cookies to work.
Danny Jansen 10 Reputation points

2025-08-22T08:52:34.15+00:00

This is not the the case. Have clients of which a few use Conditional Access policies. All clients are affected.
David VanSickle 5 Reputation points

2025-08-22T13:09:32.44+00:00

Danny, correct, that's what we were told when we reached out to Microsoft Support proactively in July, which we now know was inaccurate.
SColley 20 Reputation points

2025-08-26T14:06:45.4166667+00:00

In my user case obtaining the tokens from a browser provides a useful workaround (for low level file stuff). I already use OAuth 2.0 for interacting with other Microsoft APIs

Answer 5

Anonymous

Hi @Paul Graham1
Based on the update notification in Message Center, Microsoft 365 will update default settings to enhance security by blocking legacy authentication protocols and requiring admin consent for third-party app access. Changes start mid-July 2025 and complete by August 2025. Organizations should assess configurations, notify stakeholders, update documentation, and configure the Admin Consent workflow.
Legacy authentication protocols like RPS (Relying Party Suite) are vulnerable to brute-force and phishing attacks due to non-modern authentication. Blocking this prevents applications that are using outdated methods from accessing SharePoint and OneDrive via browser.
For more details, visit the Microsoft 365 Admin Center: https://admin.microsoft.com/?ref=MessageCenter/:/messages/MC1097272

I hope this information is helpful.

Danny Jansen 10 Reputation points

2025-08-20T09:13:42.4533333+00:00

That is only about updating default settings. Not changing the current setting or disabling SAML authentication for SharePoint Online with User Credentials as a whole. Legacy Authentication is vulnerable but that can be mitigated by using conditional access policies.