I'm sure that this use case has a known solution, but I can't find anything on google or I don't know which keywords to use. We are building an Angular app that is backed by a Rest Api. For Authorization we are using OAUTH 2 and are storing the token in a HTTP only Cookie and are also using XSRF protection ( Cross Site Request Forgery Protection )

We also got a request, to create a mobile app. I didn't find any clear material on how to expose the REST Api to the mobile app, without creating a possibility that a hacker could create a fake client that could impersonate our service, and fool Users into logging in using the fake client.


Let me explain more. Let's assume the following scenario.

The api is hosted on api.com . The api has two endpoints

  • /Token -> this endpoint will generate a JWT token, if the credentials passed with POST are valid

  • /GetData -> this is an endpoint, that will be accessible by an authorized user.

the single page app is hosted on spa.com.

Our security architecture is based on this article . The main idea is that it's unsafe to store jwt tokens in the localstorage and we should leverage the cookies for this. The api will set two cookies after a successful request to /Login

  • A http only cookie, that contains the jwt token. This cookie will be passed in the following request only to the domain of the API.
    • A XSRF Token. This is a random token that is not http only, but set to the domain spa.com. This cookie can only be accessed from javascript that is running on spa.com. This is a protection against XSRF, because every request, that is sent from the SPA, will contain this token in the header of the request.

I'm not a security expert, but based on reading an materials from stormpath and others, I think that this is a decent security architecture for the web app.

Second Scenario, mobile app.

As I said, the API checks for two tokens, in order to authorize a user. Let's imagine, there is a third endpoint on api.com:

  • /TokenMobile -> this endpoint will get the credentials that are send by a mobile app.

As we all know, mobile apps are not safe. They can be decompiled. SSL can be circumvent. An hacker, with enough time and knowledge could figure out how i'm doing all my requests, and how i'm authorizing a user. This hacker could build a makeshift website that looks similar to our app, and use the mobile endpoints to login the user. Of course, this can be possible with some social engineering .

So my questions: Am I missing something? Can I protect my users from service impersonation? Am I paranoid? Is this use case really a security problem?

  • Could you please elaborate: are you worried people will create mobile apps that will use your REST API and that you want to avoid this? or are you worried that people will trick your mobile app to use their own forged REST API? – HamZa Jan 15 '16 at 14:34
  • We use jwt.io and verify all requests but if you store a token that has a short expiry and is linked to the users account verified with oAuth then someone would not have a very large window to use your API. – Sam Collins Jan 15 '16 at 15:05
  • Mobile apps have certificates associated with them, especially android apps. The user can verify that you made the app with your public key. When downloading, so no fake app. The ReSTful service key protects others who don't have the access to the account from making requests on its behalf. However a fake mobile app would compromise this obviously, but the mobile app cert should protect you. You can use expiring JWT as Sam Collins said which is more ReSTful than cookies. You can make these expire to protect the user and when they log out all the mobile app does is just delete the token. – dylan7 Jan 15 '16 at 15:44
  • For further protection u can store the token until it expires if the user logs out before their session expires. This increases security but is not restful. JWT also protect against CSRF as long as in the web site not the mobile app XSS doesn't exist. – dylan7 Jan 15 '16 at 15:46
  • Unfortunately, what you explain in your mobile situation is a problem with ReST by nature. As ReST keeps no user session it is suppose to allow anyone with the access key through. That's what makes it so scalable yet gives it a security "issue". As long as your app has a cert the app itself should be protected from forgery. Regarding the local storage on the app you can actually store it in the app's local storage. Since I use android I will use it as an example. An android app Sharedpreferences can only be access by that app and the superuser, so you can use that. – dylan7 Jan 15 '16 at 18:01

Your Answer

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

Browse other questions tagged or ask your own question.