I have an android app. It has a backend server.
What is the best way to verify that the request is made through my app ?
currently I use google auth token to verify user.
Is there any other better way ??
Backend is in PHP and hosted on VPS (not using any BaaS service).
You can do by following,
Use the additional Request Header, However, Header can be modified easily but it is being used for the prevention
Use the random token in each ongoing requests or if you want to identify the user also, you may use UUID.
However, malicious user can also spoof the identity using request modification and there is no way to prevent it but you can add some level of identification.
Related
I've been doing a lot of search about secure my api for mobile apps for Android or IOS.
Almost all examples tell user provides an user id and password somehow in a exchange for a token.
But how to prevent someone else to consume my api without my consent?
Face the following scenario:
I expose an API,
I develop, then, an app for android to consume it,
I develop, then, an app for IOS to consume it.
Other developer performs a rev. engineer in my app, creates his own app and starts to consume it without authorization.
How to prevent that?
Short answer: you can't.
Little longer answer: If you know what you are doing you can always reverse engineer a given application and use its api. You can only make it more difficult and time consuming, using authentification via tokens and device ids or usernames is a good first step. Apart from that: why would you want to close your api to outsiders? If your server code is written well there is nothing to worry about.
You can maybe secure your API on a legal basis and sue developers who use it, but that is a completely different topic.
Some clarification regarding securing the API and securing content via the API. Assume you create a server where you can send user/password and receive a token if that combination was correct. For the account-page you send said token over and the server verifys that that token is valid and returns your account page. You secured the actual content of the API. That is obviously very possible and almost a must-have unless you have no user-specific data. But still everybody can send the exact same initial request from their custom app, sending a user/pass and again receive a token, etc. You cannot really prevent the request itself or even determine that it was not send by some service not authorized by you. You can send some hashes along the request to add some security by obfuscation, but since your app has to compute them, so can the reverse engineer.
Yes, login api are open but they return a token only on successful match in your database. You should focus more on security of your data than unknown hits at your api.
SignUp API can be used for creating a user, and login for returning token of that user. Only if malicious developer has credentials, then he can access tokens and auth APIs. There is also something about DDOS attacks so you can maybe write logic to temporarily block IPs where hits frequency is high.
You can also store device ID of signing user, which seems idle for your scenario. Entertain hits from that deviceID only. Similarly, user can add more devices with their credentials. I think even Google does that (generate alerts if user creds are signed in from new device and add the device to list if user confirms). Hope this helps.
I have a rest API which create by asp.net webservice, and I have an android and IOS application which call the api and show some data to the user.
what I need is to secure my API in a way that only my application can access to the data through the api and other request rejects.
I should mention that my application are not user base so there is no login and authentication and I don't want force user login !!!
According to my search, I need query authentication (query parameters) to achieve this.
What I need is how to create this kind of query parameters and how to validate them? (Performance is too important for me)
Thanks in advance
You can use basic authentication or any token based authentication mechanism.
So on every request to your api, get the authentication headers(authenticiation tokens in http request header) and verify if client is allowed to invoke it. If it failed then send by necessary HTTP status code. You just need to ensure that the applications that you want to allow to call your api are using those security tokens in their request headers. And you can keep those credentials or security tokens in memory or file or db as you like.
I am not a security expert, but as far as I know what you want is not possible. Anything you embed on the client to authenticate your application is accessible to an attacker, who can than use that information to access your API.
I have a simple Google App Engine backend (written in Python) for an Android client. All the backend is responsible for is accepting a key and returning a value; it is a classifier in general, implemented simply by looking up the key in a Cloud SQL table, though this specific behavior will change in the future.
The backend and client communicate via Google Cloud Endpoints. I want to restrict access to my backend's API to only accept requests incoming from my client, and am wondering if OAuth 2.0 is really the way to do this.
I don't need any contextual or extra information from the user, and as such, don't want to have user action to grant any type of authorization. All I need to do is be certain the request came from my app. I was considering simply generating a static key and hardcoding it in my client and backend, but I thought there must be a more elegant way to do this.
TL;DR: How can I restrict access to my backend only to my client/app without needing user context/input, by OAuth 2.0 or otherwise?
I don't know if the OP solved their problem but I am posting this here for others. I have wasted quite a few hours on this particular issue.
Steps :
1.Create an oAuth 2.0 client ID for your Android client.
2.Specify the Client IDs in the allowed_client_ids argument of the endpoints.api. In this case (Android), supply both its Android client ID and a web client ID in allowed_client_ids.
3.Supply the audiences argument as well in endpoints.api which is set to the web client ID.
4.Add a user check to the protected methods.
5.Redeploy the API backend.
6.Regenerate the client libraries.
We're developing a JSON REST API in Rails to be consumed by an Android application, which we are also developing. Is there any way to secure the API such that it can only be used by our specific Android application?
The API is read-only, and does not involve any kind of user-related or otherwise sensitive information. But to the extent that is reasonable we'd like to prevent abuse and restrict its use to only our app.
I could easily add an authentication token to the API and distribute it with the app, but:
We'd probably have to move the API over to SSL, if we use BASIC auth.
It's probably trivial for a determined person to open up the Android APK binary and uncover the auth token anyway.
The situation seems analogous to a café posting their WiFi password on the shop counter- you have to give the secret out to everyone who wants to use your service, so it almost seems pointless to have it in the first place.
What's the most reasonable approach to take?
Wanting to secure a probably public undocumented API so it can only be accessed by one application, means you want to stop people from using your API who are determinate of using your API.
Meaning people who would try everything possible to use your API.
If this is not the case adding a Auth token won't be trivial but at least a big stepping stone for people who stumble upon your API. And not a very bad idea to implement this.
Because this authentication isn't user based but application based and you don't want authentication to rely on user input. The request must be purely done so by the application.
Meaning you will have to do so anyway(adding hardcoded token). Only you make it very very difficult for a determined person to uncover the access and request tokens and the methods.
It depends on the situation, but I would go for the SSL and hardcoded token.
Some extra security:
Release an access token to the application which only need to send a
request token periodically. Meaning less chance people intercept the
hardcoded request token, but a session based access token which
expires. Maybe just do this once for every application install.
Encode this request token before sending it through the air. Meaning
people have to decompile your app.
Obfuscate code (make it more difficult to decompile).
I am trying to get Authorization for Google Buzz,Contacts from an Android application.
The flow is similar to this.
The user chooses if he wants to use Buzz.
Using OAuth/Client Auth, we need to get a one-time authorization code.
This code would be used by a web service to periodically read Buzz feeds.
Now, the problem is how do I obtain the authorization code (Not temporary token) from the Android App and send it to the webservice.
I could use the normal OAuth2.0 and use my webservice as the redirect URL to obtain the code. But in that case how can I let the webservice know that the code pertains to which user?
Can I pass extra information with the OAuth dance?
I strongly recommend using OAuth 2. The flow is much better for the end user and it's a lot easier to implement something like this. Additionally, it uses bearer tokens, which means that you can maintain your refresh token server side where it's actually secure and only ship access tokens to the Android when they're needed.
The downside of this approach is that effectively every time your app loads it needs to phone home to get the latest access token. But once it has that access token, it can make whatever API calls it needs to, directly to the Buzz and Contacts APIs.
However, to do this, you don't pass extra information with the OAuth dance. Instead, your Android app needs to have already securely identified which user is signed in with your app, and then make sure the server only ever sends back access tokens associated with the authenticated user. If it doesn't have an up-to-date access token for that user, it would need to make a request out to Google's authorization server to get the latest access token, and then pass it up to the client. So there's certainly a strong potential for some latency there, because that generally needs to be a synchronous call, but that's usually a small price to pay for the advantages OAuth 2 gives you over OAuth 1.