authenticationsecuritycookiesmobile

Authorization (and security, in general) for web and mobile apps of the same service

Help me to understand how to implement proper security for web and mobile apps, which would be enough for my case.

What I have:

  1. Backend. Some sort of Stateless REST API, which consumes and produces JSON text. Does not store any kind of state.
  2. Web application. Main portal to the service functionality.
  3. Mobile applicaiton. Provides a reduced a set of functions to users of the service

I am not going to store any state on the backend. Instead, I am going to delegate this to both mobile and web browser applications. Now here comes the question of security. How do I properly secure that?

Since session mechanism does not really work for me, I decided to go with JWT. In my JWT I am going to store user Id and some other information like, for instance, user's privilegies.

For mobile app, I am going to send this token as a part of a response and the app will store it inside its secure store. Each request it will send this token as Authorization Header.

For web app, I am going to send this token via HttpOnly cookie. This token, thus, will be included in every request from the client. The problem now is a possible CSRF-attack. To address that I thought of the following. Each user "session" will be associated with CSRF token. Since I can't store this token on the server (remember, stateless API), I can send it as encrypted (again, with JWT) token to the client via HttpOnly cookie and non-crypted in a regular cookie.

Now, every request the web client will use non-crypted token from the cookie and send it back to the server. The server will check if this token matches from the Encrypted one which is stored in HttpOnly cookie.

Also, I am going to use different URL endpoints for web and mobile web apps. What for? In order to keep auth mechanisms described above separate - I believe this will help me to keep the service secure.

Do you think it is an OK solution? What problems do you see here?

Solution

  • In general, what you described looks good and pretty standard. However, if I understand correctly, the CSRF protection is flawed.

    To make sure I understand correctly: a csrf token would be stored in an encrypted httpOnly cookie, only to be sent back to the server as reference. Another cookie would have the same value but unencrypted, in a plain (non-httpOnly) cookie, and the server would compare these two. What's the point? An attacker would still be able to create a webpage to have a user make an request to your website, and both cookies would still be sent.

    The reference cookie is ok to be in the httpOnly cookie for reference, but the other one should not be a cookie. It could for example be a request header value that you add to all requests. The client could receive it in a response, but not as a cookie. With jQuery in the web app, you can use the beforeSend hook to add it to all subsequent requests as a header. This way an attacker could not make valid requests from another domain.