This definitely works, assuming consecutive requests carry a cookie that is added to the very first request to the Login action.
In the case of a browser using ajax, this works out of the box since consecutive ajax requests carry all cookies issued by the same domain and added to the current browser session.
In the case of a native application, this can be more complicated because it means you need to use the same instance of the client proxy server, or you will find a way to have temporary local storage for cookies for authentication and add these cookies to each request.
However, there is a potential drawback to this request: you assume that the login method may use the username / password in the active script to create cookie forms. And it's not always that simple.
This is because your site could potentially be combined with an external identity provider (ADFS, Azure Active Directory, Google, Facebook, etc.) so that the actual authentication takes place on another website and your site receives a response, which matches the single-character protocol used (OAuth2, WS-Federation).
In this case, there really is no easy way to use a pairing username / password on the server side to get the user identity.
The workaround in this case, when the identity provider is unknown, is to place the web browser control (if possible) and allows it to execute a passive authentication script - this means that you go to the application page and allow the web browser to automatically control 302 on login page, no matter how many redirects are required. Then the user provides the credentials on the supplierβs page, and the web browser redirects everything back to your application, and there you will catch the identity on the server side, close the web browser control and somehow (depending on the actual web browser host ) read the authentication cookie so that it can be attached to further requests.
It sounds complicated, but we found some federation scenarios where the actual SSO protocols between the parties were not guaranteed, and such a simulation of a passive script from the built-in web browser was the only reliable way.
Wiktor zychla
source share