I have an AccountController for my Web Api site that uses the default implementation for the login:
// POST: /Account/Login
[HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public async Task<ActionResult> Login(LoginViewModel model, string returnUrl)
{
if (!ModelState.IsValid)
{
return View(model);
}
// This doesn't count login failures towards account lockout
// To enable password failures to trigger account lockout, change to shouldLockout: true
var result = await SignInManager.PasswordSignInAsync(model.Email, model.Password, model.RememberMe, shouldLockout: false);
switch (result)
{
case SignInStatus.Success:
return RedirectToLocal(returnUrl);
case SignInStatus.LockedOut:
return View("Lockout");
case SignInStatus.RequiresVerification:
return RedirectToAction("SendCode", new { ReturnUrl = returnUrl, RememberMe = model.RememberMe });
case SignInStatus.Failure:
default:
ModelState.AddModelError("", "Invalid login attempt.");
return View(model);
}
}
This works fine for the web, but if I'm using a client app like UWP
or Xamarin
this becomes an issue if I want to login without using a WebView
because it looks like the Web Api
is coupled to the web since it relies on the anti-forgery
token being generated in the View and posted back on submit. Let's say I want that client app to just uses textboxes and a submit button for the login like most mobile apps I see. They usually don't pop up a WebView
.
Is the only solution to create another method which logs in the user without the anti-forgery token? That seems a bit messy and doesn't follow DRY principles very well, not to mention a potential security risk.
Anti-Forgery Tokens The server includes two tokens in the response. One token is sent as a cookie. The other is placed in a hidden form field. The tokens are generated randomly so that an adversary cannot guess the values.
AntiForgeryToken(String)Use the AntiForgeryToken() method instead. To specify custom data to be embedded within the token, use the static AntiForgeryConfig. AdditionalDataProvider property. Generates a hidden form field (anti-forgery token) that is validated when the form is submitted.
ASP.NET Core uses a hidden field to store the anti-forgery token and uses the ValidateAntiForgeryToken attribute to validate the token. As the token is sent to the browser in a hidden field, it is also stored in an HttpOnly cookie.
TYPE. __RequestVerificationToken. www.grpgroup.co.uk. This is an anti-forgery cookie set by web applications built using ASP.NET MVC technologies. It is designed to stop unauthorised posting of content to a website, known as Cross-Site Request Forgery.
The answer for this was to bypass the anti-forgery token completely by making a POST to the /Token Endpoint and overriding the ApplicationOAuthProvider to allow for client access. See this stackexchange for details:
WebAPI [Authorize] returning error when logged in
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With