2

We have an existing single-page web application powered by ASP.NET WebApi endpoints. These endpoints leverage SimpleMembership and Forms Authentication to handle authorization and authentication:

    [System.Web.Http.HttpPost]
    [Route("api/login")]
    [System.Web.Http.AllowAnonymous]
    public HttpResponseMessage LogIn(LoginModel model) {
        if (!WebSecurity.UserExists(model.Username))
            return Request.CreateResponse(HttpStatusCode.OK, new ApiResponseDto() { Success = false, Error = "Email or Password is incorrect." });
        if (_userService.LoginWork(model.Username) && WebSecurity.Login(model.Username, model.Password, persistCookie: true)) {
            return Request.CreateResponse(HttpStatusCode.OK, new ApiResponseDto() { Data = true });
        }
        LogOut();
        return Request.CreateResponse(HttpStatusCode.OK, new ApiResponseDto() { Success = false, Error = "Login Failed" });
    }

We are now developing a native iOS app and would like to reuse these API endpoints in the name of simplicity. To do this, we're using CSRF tokens as well as cookies to handle auth from both native and web apps.

I like the idea of keeping things simple and not rewriting ~100 API endpoints just to support mobile, but not if I have to compromise around security. Is this solution "as secure" as the standard implementation of say a pure OAuth2 token-based implementation? If not, why?

2
+50

Sure, why wouldn't it be? You just lose (a lot of) the flexibility that is included in the many use cases of OAuth, which I assume you do not need. In particular, if you only care about your own app, and not about delegating access to others and/or allowing users to login with other identity providers, then you are just fine with this set-up. That said, if you are going to upgrade in the future, upgrade to OpenID Connect, instead of 'pure OAuth'.

A couple of remarks:

  • You will likely need to store the authentication token (which you normally include in a cookie) in some local storage of the device, as cookies do not exist in native apps. So you might need some kind of 'translator' in your app which catches the 'set-cookie' command and stores its value in the local device storage. Likewise for the other way around.
  • CSRF attacks do not exist in real native apps. However, if you use the same endpoints for both browser and app, you'll likely need to keep using them.
  • Use HTTPS (and possibly HSTS and HPKP) to secure your tokens during transport.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.