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.
Related
I have a server developed in laravel. I have an android application that can send POST and GET request to my server. I found that i can send POST and GET request from any other systems if have the link to my api. I want to authenticate my API and only allow my android application to POST and GET from my API. Please note that i dont have user login in my android part. I simply want to authenticate my android app to access those APIs.
If you want only your mobile application to make API calls, you can't. Your API doesn't know who is sending the information, he can only check if the information is correct and proceed with your endpoint. Like others have said use JWT/Authentication to limit who can use your API by creating an account or requesting a token, but there's nothing to prevent the user from taking his token and use it on his browser or tool of his choice like Postman.
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.
My Android app needs to send an authorization code to my server so that the server can use that to acquire an access token for the user's Google Drive account. I have been trying to figure out how to acquire the authorization code and I found this in the Google API documentation (Using OAuth 2.0 for Installed Applications):
This sequence starts by redirecting a browser (system browser or
embedded in the application as a web view) to a Google URL with a set
of query parameters that indicate the type of Google API access the
application requires. Like other scenarios, Google handles the user
authentication and consent, but the result of the sequence is an
authorization code. The authorization code is returned in the title
bar of the browser or as a query string parameter (depends on the
parameters sent in the request).
After receiving the authorization code, the application can exchange
the code for an access token and a refresh token. The application
presents its client_id and client_secret (obtained during application
registration) and the authorization code during this exchange. Upon
receipt of the refresh token, the application should store it for
future use. The access token gives your application access to a Google
API.
Now I am not sure how to get this authorization code in my Android app since the Android examples I have seen seem to get the access tokens directly. I am looking at the Android AccountManager class and it has a method getAuthToken but this seems to refer to the access token and not the authorization code.
So how does one acquire the authorization code that can be shared with a server? If it is possible I would greatly appreciate some example code. If this is not possible what are the possible workarounds?
You may want to take a look at the Cross-client Identity document. It should keep you from needing to pass user tokens back and forth.
I believe you can actually take the access token returned by the Android AccountManager, send this to your server, then have your server make a call against the Google Drive API using that same access token - it is a bearer token and not bound to the channel that created it, so please take good care of it and only send over encrypted connections.
Documentation on how to get that access token can be found here:
https://developers.google.com/drive/quickstart-android
While that access token is good for immediate use, it will expire in less than 1 hour, so if you are looking for a solution that enables your backend server to have continued access to the Drive data, without the user being present at your app at the time of request, an alternate approach will be needed.
I'm developing a small app, I have an asp.net web application with a WCF data service. On my app, the data service is exposed to Android, and I want to authenticate the users.
The user's credentials will be stored in a database.
Is it possible to use membership and role provider to authenticate the users?
If not, what is the best authentication method, so that I can give permissions to some operations and deny it for other operations?
The option I've seen used often is to use HTTPS and pass through your user credentials on each call using a RESTful service. Obviously keep your security layer at the server side and return failure codes when the credentials aren't valid.
There are tonnes of examples on the web, including this SO answer.
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.