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

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.

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.

> 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.

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 :)

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

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.

Authentication example is a good place to start. Android stores credentials in the Account Manager, you can view accounts in Android's settings. This will automatically store tokens, prompt the user for credentials if expired or missing, refresh tokens etc. I find the http part of this example lacking or old. Extending android's AccountAuthenticatorActivity is a great helper to parse serialized data to the layout and back to the internet.

Username and passwords can be safe when placed in SharedPreferences. Using https in connecting to a server should be good enough as well.