1

I have been reading about authentication and authorization for the past few days and I still have not figured out what would be a reasonable way to deal with this for both mobile and web applications.

From what I read, when it comes to a web application, using an access and refresh (JWT) tokens seems to be quite popular. Now, when it comes to storing, there seems to be a lot of different opinions. Some people prefer to store the access token in the localStorage, to avoid CSRFs, however, others point out it is a bad practice due to XSS attacks and having the access token in an httpOnly cookie, with a CSRF token in a normal cookie would be better. (tho in my opinion we still have the XSS problem here as the normal cookie can still be exploited by XSS).

As mobile applications do not have cookies, I guess the second option is gone, and if the REST API will be used for both mobile and web, when logging in (authenticating), the token should be sent in the response and saved in localStorage. How would this be handled for the mobile application?

Furthermore, how would the refresh token be stored for a mobile application? The case, where we store the access token in localStorage, I guess we would have the refresh token in an httpOnly cookie, however, as already mentioned, mobile applications are not browser based, so I guess this would not be an option. Therefor, I still do not understand, how can it be possible to create a secure REST API, which is available both for mobile and web applications.

Improve this question
1
  • 1
    Mobile applications can store state in files and databases, no?
    – multithr3at3d
    Commented Nov 15, 2020 at 17:44

1 Answer 1

Reset to default
3

As mobile applications do not have cookies - this is a wrong statement. The support of cookies is provided by the OS. You may want to look at CookieManager for Android or HTTPCookieStorage for iOS. Both Android and iOS apps do support cookies including httpOnly.

For JWT, the server should not care if the client is a browser or a native mobile app. If the server provides HTTP based API, it should expect that the clients do understand and do implement HTTP. This includes that clients do support cookies. Furthermore, if security functionality on the server depends on any assumptions about the client, it can be dangerous, because malicious users can manipulate the responses.

TLDR: For the REST API to support JWT there is no need to distinguish between mobile and web clients.

Improve this answer
3
  • i had a similar question as the OP. Would it be better to use jwt and store it in a cookie. i.e. a stateful jwt for both spa and mobile client. Or have a separate login endpoints for browser and mobile where browser (spa) stores jwt in a cookie and mobile client stores it locally.
    – EI-01
    Commented Nov 30, 2020 at 4:08
  • @EI-01: Do you mean, that herewith is also your question answered? Or is something no clear?
    – mentallurg
    Commented Nov 30, 2020 at 19:26
  • what i understood from your answer that its ok to store JWT in a cookie. I was wondering if theres any significant benefit from actually passing JWT to a native mobile app to be saved directly on a mobile client than saving it to a cookie manager?
    – EI-01
    Commented Dec 1, 2020 at 5:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .