How do popular apps authenticate user requests from their mobile app to their server?

Question

Say I have an Android application that connects to a .Net API for receiving/setting data. The confusion that I have is regarding how to sign-up/login the user first time and authenticate it every time they make a request to the API.

• If I just use username/password based authentication they won't be safe enough?
• And I can't save that username/password in the device for of course security reasons?
• Should I issue a GUID for every user at the sign-up, save it in their device and retrieve every time during an API request?

What other patterns are available and which are most efficient and secure, I just need a process flow for it. Can someone tell me what method famous android applications like Facebook, FourSquare, or Twitter use to authenticate every request coming from their mobile application to their server?

Sorry in advance if that's not some public information.

Solution 1

I imagine they use a "token" based security system, so the password is actually never stored anywhere, just used the first time to authenticate. So the app initially posts the username/password (over ssl) and the server returns a token that the app stores. For subsequent sync attempts the token is sent first, the server checks it is valid, and then allows other data to be posted.

The token should have an expiry so the server can re-request an authentication attempt.

If you hook into the sync adaptor from within the Android Framework that will give you the ability to sync and authenticate all under the hood.

http://developer.android.com/training/sync-adapters/creating-sync-adapter.html

If you check the accounts under Settings on your device you'll see what I mean.

Solution 2

If I just use username/password based authentication they won't be safe enough?

No, because you are only identifying the WHO is accessing the API server, but not the WHAT is accessing it.

The Difference Between WHO and WHAT is Accessing the API Server

To better understand the differences between the WHO and the WHAT are accessing an API server, let’s use this picture:

The Intended Communication Channel represents the mobile app being used as you expected, by a legit user without any malicious intentions, using an untampered version of the mobile app, and communicating directly with the API server without being man in the middle attacked.

The actual channel may represent several different scenarios, like a legit user with malicious intentions that may be using a repackaged version of the mobile app, a hacker using the genuine version of the mobile app, while man in the middle attacking it, to understand how the communication between the mobile app and the API server is being done in order to be able to automate attacks against your API. Many other scenarios are possible, but we will not enumerate each one here.

I hope that by now you may already have a clue why the WHO and the WHAT are not the same, but if not it will become clear in a moment.

The WHO is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.

OAUTH

Generally, OAuth provides to clients a "secure delegated access" to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials. Designed specifically to work with Hypertext Transfer Protocol (HTTP), OAuth essentially allows access tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner. The third party then uses the access token to access the protected resources hosted by the resource server.

OpenID Connect

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.

While user authentication may let the API server know WHO is using the API, it cannot guarantee that the requests have originated from WHAT you expect, the original version of the mobile app.

Now we need a way to identify WHAT is calling the API server, and here things become more tricky than most developers may think. The WHAT is the thing making the request to the API server. Is it really a genuine instance of the mobile app, or is a bot, an automated script or an attacker manually poking around with the API server, using a tool like Postman?

For your surprise you may end up discovering that It can be one of the legit users using a repackaged version of the mobile app or an automated script that is trying to gamify and take advantage of the service provided by the application.

Well, to identify the WHAT, developers tend to resort to an API key that usually they hard-code in the code of their mobile app. Some developers go the extra mile and compute the key at run-time in the mobile app, thus it becomes a runtime secret as opposed to the former approach when a static secret is embedded in the code.

The above write-up was extracted from an article I wrote, entitled WHY DOES YOUR MOBILE APP NEED AN API KEY?, and that you can read in full here, that is the first article in a series of articles about API keys.

Storing Sensitive Data in the Client Device

And I can't save that username/password in the device for of course security reasons? Should I issue a GUID for every user at the sign-up, save it in their device and retrieve every time during an API request?

Anything you save in the device, even if encrypted, can be reverse engineered during run-time with tools like Frida or Xposed.

Frida

Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.

xPosed

Xposed is a framework for modules that can change the behavior of the system and apps without touching any APKs. That's great because it means that modules can work for different versions and even ROMs without any changes (as long as the original code

In a device the attacker controls he can also use a proxy to perform a Man in the Middle Attack to extract any secret you may use to identify the WHAT or the WHO as I show in the article Steal that API Key with a Man in the Attack:

While we can use advanced techniques, like JNI/NDK, to hide the API key in the mobile app code, it will not impede someone from performing a MitM attack in order to steal the API key. In fact a MitM attack is easy to the point that it can even be achieved by non developers.

So now what... Am I doomed to the point I cannot protect my API server from being abused??? No quiet so... hope still exists!!!

Possible Solutions

Can someone tell me what method famous android applications like Facebook, FourSquare, or Twitter use to authenticate every request coming from their mobile application to their server?

Sorry but I don't have enough knowledge on this apps to be able to elucidate you, but I can point you to some other approaches.

What other patterns are available and which are most efficient and secure, I just need a process flow for it.

So anything that runs on the client side and needs some secret to access an API can be abused in different ways and you can learn more on this series of articles about Mobile API Security Techniques. This articles will teach you how API Keys, User Access Tokens, HMAC and TLS Pinning can be used to protect the API and how they can be bypassed.

To solve the problem of WHAT is accessing your mobile app you need to use one or all the solutions mentioned in the series of articles about Mobile API Security Techniques that I mentioned above and accepted that they can only make unauthorized access to your API server harder to bypass but not impossible.

A better solution can be employed by using a Mobile App Attestation solution that will enable the API server to know is receiving only requests from a genuine mobile app.

Mobile App Attestation

The use of a Mobile App Attestation solution will enable the API server to know WHAT is sending the requests, thus allowing to respond only to requests from a genuine mobile app while rejecting all other requests from unsafe sources.

The role of a Mobile App Attestation solution is to guarantee at run-time that your mobile app was not tampered with, is not running in a rooted device, not being instrumented by a framework like xPosed or Frida, not being MitM attacked, and this is achieved by running an SDK in the background. The service running in the cloud will challenge the app, and based on the responses it will attest the integrity of the mobile app and device is running on, thus the SDK will never be responsible for any decisions.

On successful attestation of the mobile app integrity a short time lived JWT token is issued and signed with a secret that only the API server and the Mobile App Attestation service in the cloud are aware. In the case of failure on the mobile app attestation the JWT token is signed with a secret that the API server does not know.

Now the App must sent with every API call the JWT token in the headers of the request. This will allow the API server to only serve requests when it can verify the signature and expiration time in the JWT token and refuse them when it fails the verification.

Once the secret used by the Mobile App Attestation service is not known by the mobile app, is not possible to reverse engineer it at run-time even when the App is tampered, running in a rooted device or communicating over a connection that is being the target of a Man in the Middle Attack.

The Mobile App Attestation service already exists as a SAAS solution at Approov(I work here) that provides SDKs for several platforms, including iOS, Android, React Native and others. The integration will also need a small check in the API server code to verify the JWT token issued by the cloud service. This check is necessary for the API server to be able to decide what requests to serve and what ones to deny.

Conclusion

In the end, the solution to use in order to protect your API server must be chosen in accordance with the value of what you are trying to protect and the legal requirements for that type of data, like the GDPR regulations in Europe.

DO YOU WANT TO GO THE EXTRA MILE?

OWASP Mobile Security Project - Top 10 risks

The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.

Solution 3

Basically these famous use OAuth protocol (1)/ framework (2). Even though it has to be a standard, each of these had different implementations of this protocol/framework. So we have to be very careful when it comes to integration.

Example: Dropbox still uses OAuth 1 and recently came up with OAuth 2 support.

Back to Answer, As, peterpan stated, its is a token based way of authentication is one time thing and out of the equation.These tokens are expired or that power is given to the developer in some cases.

The interesting thing behind this is that, resource access scope can be defined rather than allowing the client application to keep the user names, passwords which is dangerous.

This is the basic illustration of how this works.

I will update the answer after I get more details on this, since I am working in this area these days :)

Solution 4

I am newbie but I will try to give logical solution for the given question.

There will be two options, [1] For every URI, http authentication will be perform where user's entered credentials will be verified and user shall access resources.

[2] Another approach could be, a user shall authenticated and on every authentication a unique token will be generated. Using generated token, user shall access resources.

Though I'm not sure which approach could be best suitable for mobile application.

Solution 5

I was searching for exactly the same thing and found google way, something like peterpan said, but through Google APIs. Try this link and Google your way through it, I am starting also! I'll post new info while I`m at it!

http://developer.android.com/google/auth/http-auth.html

View more solutions

Comments

[Michael Helwig]

You can use SharedPreferences but your data there is not encrypted by default. If you are worried about that, see e.g. this discussion on SO: stackoverflow.com/questions/785973/…

[Brill Pappin]

SharedPreferences is not a safe place to store credentials. Any rooted device (which is not hard to do) will expose those credentials. Instead, use the built in account API.

[Darthmail]

The SharedPreferences can also be downloaded from an unrooted devices, which if I`m not mistaken is possible via the backup mechanism of the Android system. There are different tools to get readable files out of an Android backup file.

[ToolmakerSteve]

@BrillPappin Question about your comment. The credentials being stored are the user's email and password, plus a token to send that represents current authentication with that email. If the user chooses to expose their own credentials to themselves, via rooting, how is that a risk?

[Brill Pappin]

The risk is twofold. 1) any easily accessed sensitive data you must assume will be accessed. You might not really care, but someone else might. 2) any storage of a passphrase is insecure.

[Brill Pappin]

@ToolmakerSteve I'd suggest that you should not be storing the users password ever. If you have a token why are you storing the password? If the token expires, and is not rotated, the user should be required to enter it again. That is the whole point of secure authentication.

[Martin]

Yeah, I misspoke. Although you can put passwords in sharedPrefs, I don't and wouldn't. And yes, it may not be "secure", but there is a whole class of apps for which saving a username or any other credentials - is perfectly fine. The data is such that of someone really wanted to hack it there would be little worthwhile to obtain. Items such as player scores come to mind. But just because it isn't secure doesn't mean it isn't a valuable tool in the right circumstances

[Xfce4]

Thank you for your detailed explanation. It looks like a secure app-server connection is not well established and standardized yet. Can we call it that way?

[Exadra37]

The nature of how Internet was designed is the the base of the problem. Initially the internet was designed based on trust, just more recently security became a concern.

[Xfce4]

Yeah, you have a point. It would all be much different if it was designed with cautions in the first place. But from that point of view, don't you think Android would be designed in a more secure fashion?

[Exadra37]

Every software that exists nowadays could have been better designed if security was a main concern from day zero, but more often then not it isn't, and even when it is, we always have the less well though decisions. Security will be always a mouse/cat game between bad and good actors.

[Exadra37]

Nowadays Android is very strong in Security, some articles in the internet even Advocate that its more secure then iOS, because of the zero day exploits being more well paid then the ones for iOS. Also you need to remember that iOS the advantage of being closed source, thus bad actors cannot pry in its source code like they can in Android.

[Xfce4]

I was not doing a comparison between between Android and iOS, bu I was inspecting Android in itself. Anyway thanks a lot for the valuable information you provided.