If you’re doing a custom solution you should provide exactly what you’re doing as these posts and code samples are highly confusing which makes hard when trying to identify what’s actually happen before I’m able to help identify & resolve issues. Throwing NotImplementedException means your Custom AuthProvider does not allow Authentication via a normal Authenticate Request, so I don’t see how it could ever work. Then you have a ValidateSomethingRequest which looks off named as it looks like it’s doing your own Authentication, but I don’t understand what populated the original session that you’re retrieving with SessionAs<AuthUserSession>()? Switching over to use the permanent ss-pid Cookie with SessionOptions.Permanent before retrieving the session is confusing as well it could only work if the Session was saved against the permanent Cookie previously even though the Request is marked to use the temporary ss-id Cookie.
You can read about the Async Auth Provider changes in the latest v5.10 Release, e.g. you can use continue to use your previous sync Auth Providers with AuthProviderSync. But I don’t see how your code samples were supposed to work so I’m not sure if using the existing sync Auth Provider would make a difference. Maybe you’re relying on a prior behavior of new Authentication Requests not generating new Cookies which you can revert with AuthFeature.GenerateNewSessionCookiesOnAuthentication=false but then you don’t appear to be able to authenticate normally so maybe that’s not going to have any effect.
You also always need to specify if you’re using Blazor in each Post, esp. Blazor WASM which is a crippled .NET Runtime which has limited support & capabilities, e.g. the HttpClient is a shim over W3C’s JS fetch API (i.e. not the real HttpClient library implementation), you can refer to this previous answer on how to sent fetch’s credentials:‘include’ in the Blazor JsonHttpClient which may or may not resolve your issue.