I am developing an HTML5 mobile application which I am planning to port to Android also using Phonegap. I want to use AWS DynamoDB for storing my users data. I know that amazon has a http api but it is too complicated. Some of my queries are
If I use the HTTP api, wouldn't it expose my credentials? (Same qquery for dynode)
What are the alternatives? I have a EC2 instance so hosting a server is not a problem.
I would appreciate your suggestions on this.
If you connect directly from your phone application, to dynamodb, you will risk exposing your credentials.
The general way to handle this is to have a json REST api through which the phone application can authenticate and make requests to the datastore. Your application would communicate with this api.
In this case, each user would likely have its own authentication to your server application.
Related
I have a few applications. For each I need an authentication service, I have written this service separately. How is it possible to use this authentication service in different web applications?
The reason for separating is that I do not want to rewrite this service multiple times.
Would lerna.js be an idea to implement such a construct?
Or are there any more sensible solutions?
So you are using microservice architecture where you have written a completely separate application for authentication. This is completely fine.
Now what you would do is, deploy all the microservices and let other services to use auth server for authentication. How would you do that? Well, you can do it using our friendly RESTful architecture. Lets say you have a service X. When you try to access X, X would send a request to Auth server. Auth server will response back to the service X if you have access or not. If you have access then X service would response you back with data or authentication error.
Do you get me?
I have a database with API written in Python (Flask). I want to build a frontend which makes requests to API and display data. But I want to control the access to the API.
I couldn't implement authorization because my web app is a public client type (according to Oauth RFC) -- so there is no way to store credentials securely to authenticate the app. And I don't need user authentication (the web app is a simple catalog with interactive filters and cart).
So I need somehow to protect JS-code (uglifying/obfuscating is not enough, because I have ajax requests with URIs) or rebuild the whole web app in some way to hide ajax requests and secure the API.
Does anybody has any ideas and hints how is it possible to secure API + frontend web-app without user authentication?
It should be trivial because there're a lot of products catalogs which work in interactive manner like tesco and its filtering mechanism. But I don't understand how.
Could you give a hint?
The previous question REST API: user-agent-based client (app) authorization
The API is a backend to a Web app and mobile app. I don't need user authentication. I simply need a way to secure access to this API.
I just need to ensure only web app and mobile app can talk to this backend and no one else.
If you are indeed using Google Cloud Endpoints, what you want is easy to do.
You need to log into the developer console and go under API Manager -> Credentials. There you can generate access keys for each of your clients. Then you add those tokens to your endpoints using the provided annotations. You cloud endpoints will only serve requests that come from one of the clients you have specified.
tech stack
Ruby on Rails
RESTful JSON API
Backbone + Handlebar templates + Underscore + JQuery
OAuth2
I am working on a webapp where I would like all the communication between the browser and controller via JSON RESTful API. I would also like to use the same API for different client apps like mobile and desktop apps.
I am considering the OAuth authentication mechanism for API. This fits in perfectly with Desktop and Mobile app. However if I would use the OAuth for front end too; then that basically means that an end user would be issued an access_token and that would be used to make subsequent requests.
Is there a clean way to handle session timeouts ONLY in webapp while using the same oauth token strategy for Authentication without having to wrap it with a separate persistent session?
Are there any good practices or frameworks that allows us to expose API for client as well as webapp consumption while catering to the specific nuances of each?
I know Foursquare currently uses the OAuth API for both clients and web; but curious as to how they handle authentication with that?
Any help with ideas and implementation would be much appreciated.
I know that there are many similar questions posted, but none of them refers to an HTML/javascript app where the user can access the code.
I have a private REST API written in nodejs. It is private because its only purpose is to server my HTML5 clients apps (Chrome app and Adobe Air app). So an API key is not a good solution since any user can see the javascript code.
I want to avoid bots creating accounts on my server and consuming my resources.
Is there any way to acomplish this?
An API key is a decent solution especially if you require constraints on the API key's request origin; consider that you should only accept an API key if the originating web request comes from an authorized source, such as your private domain. If a web request comes from an unauthorized domain, you could simply deny processing the request.
You can improve the security of this mechanism by utilizing a specialized encoding scheme, such as a hash-based message authentication code (HMAC). The following resource explains this mechanism clearly:
http://cloud.dzone.com/news/using-api-keys-effectively
What you want to do is employ mutually-authenticated SSL, so that your server will only accept incoming connections from your app and your app will only communicate with your server.
Here's the high-level approach. Create a self-signed server SSL certificate and deploy on your web server. If you're using Android, you can use the keytool included with the Android SDK for this purpose; if you're using another app platform, similar tools exist for them as well. Then create a self-signed client and deploy that within your application in a custom keystore included in your application as a resource (keytool will generate this as well). Configure the server to require client-side SSL authentication and to only accept the client certificate you generated. Configure the client to use that client-side certificate to identify itself and only accept the one server-side certificate you installed on your server for that part of it.
If someone/something other than your app attempts to connect to your server, the SSL connection will not be created, as the server will reject incoming SSL connections that do not present the client certificate that you have included in your app.
A step-by-step for this is a much longer answer than is warranted here. I would suggest doing this in stages as there are resources on the web about how to deal with self-signed SSL certificate in Android (I'm not as familiar with how to do this on other mobile platforms), both server and client side. There is also a complete walk-through in my book, Application Security for the Android Platform, published by O'Reilly.