I just got an Android phone, and of course I am itching to make an app for the platform.
I have an idea in mind, but it requires that I have a server that will offer REST-style services to the client phones. I have neither the skills on server security nor the money for a verified SSL certificate. I also wouldn't feel that great having people's login information (username, password) on my server, as I could get easily hacked.
So in a nutshell, will App Engine help out with these aspects? Basically, I do not trust myself in coding security-critical code, such as logins, and account creation/deletion. Maybe I'm making it seem more difficult than it really is, but I rather have that stuff taken care of already.
App Engine supports integrating with Android apps for authentication, as described here. In that respect, it's an excellent choice for a backend for an Android app.
It's good to not have unwarranted faith in your ability to write secure apps - but bear in mind that no platform is a silver bullet, and there's always possible avenues for security vulnerabilities.
Oauth in GAE works quite well, companies like Facebook and Dropbox and Twitter are using it. Access_token is send to the app (or browser) and with this access_token, the app can access the user's account without needed the username + password.
With GAE, you can use encryption (pycrypto) when storing the access_token on the user app, only to be decrypted by GAE when user logs in.
Related
I build Android app link to Google Cloud Storage. I want to allow access to GCS to my android app ONLY.
Google offers three solutions to securely connect to GCS:
Oauth 2.0 (So with google account)
Cookie-base Account (With google account too)
Service Account Authentication (With private Key, but locally installed on Android App: Very Bad if someone decompile my .apk)
Source: https://developers.google.com/storage/docs/authentication?hl=FR
Is there any other solution to connect securely over GCS ? I would like to connect on GCS to this way (Restrict to Android client ID: SHA1 to your .apk) : https://developers.google.com/appengine/docs/java/endpoints/auth
It is possible with GCS ? Should I use Blobstore to do that ?
Thanks in advance
This is something of a fundamental problem with computing. You can never completely trust that an application running on hardware that is under the total control of an unknown third party has not been somehow tampered with. There are many, many techniques to make tampering much more difficult, but remote systems will never be completely secure. There are several ways to verify that a user has a particular Google account, but you can't easily trust with certainty that a certain app is exactly your app.
That said, there are plenty of ways to design a secure application without trusting the client. What does your app need to be authorized to do? Upload objects? Download secure objects? Is there something bad that a user masquerading as your application could do?
I think you can use 1) to authenticate the information. The app will forward the authentication request to your server (with your own app login token), and when the user is validated by your own services, then the app will receive the oauth token to send to gcloud and receive the desired file.
I'm using Google's user api on Google App Engine for authentification. As nearly everyone have a Google Account and api is easy to implement, that solution is convenient.
The problem is, though, with user who do not have a Google Account (or have no idea what a Google Account is). Where the api provides a nice interface to log in/log out and redirect immediately and easily to the app, nothing is said to developers about potential new users.
So here are a couple of things worth noticing:
Google' new Google Account page (https://www.google.com/accounts/NewAccount) is pretty straightforward, but not convenient at all for new users of a GAE app: no mention of anything not Google (users who don't really know what authentification is won't have any clue of why they need to open an account with Google), dead end (won't lead anywhere in the end), ugly.
GAE Log In screen includes a link to the New Google Account page. This link is of the form:
https://www.google.com/accounts/NewAccount?continue=http%3A%2F%2Fexample.com%2F_ah%2Flogin%3Fcontinue%3Dhttp%3A%2F%2Fexample.com%2Fprofile%2F&service=ah<mpl=gm&sig=0aa0a000aa000a00000aa0000a000aa
(Where example.com is the return url provided to the API). Great! But the situation is in no way different than it was: still a dead end, still no mention of any non-Google app, still ugly).
So, I'm asking, is there any imaginative way to provide a nicer interface for new users? Have anyone have ideas of how to present the process to the new users (a video for how to create a new account? some kind of tutorial page? etc.)? Just trying to think outside of the technical box here...
Regarding the various authentication options you can check out the Java or Python docs on OpenID (http://openid.net/)
Basically this allows supporting authentication by different agents, which includes Google accounts or even your own GAE application's custom implementation.
Furthermore you can check out User Experience summary for Federated Login for more information regarding UX considerations and best practices - with user authentication.
Looking at the Google App Engine API, it seems that despite all its great features, the User API is extremely limiting. It seems you can only authenticate people who have a Google account, or use an OpenID account, or via some OAuth kung fu (handshaking with a Facebook account etc).
This appears to be a major stumbling block for anyone who wants a proprietary user base by creating user accounts within the application. In short, I don't want my users to have to use or create a Google account to access my app.
Has anyone else come across this limitation and has it been a deal breaker for using the GAE? Am I missing something? It is possible to deploy my own Spring based security etc within the app and use my own User API? Comments on this issue greatly appreciated. Thanks.
You're free to completely ignore the Users API and implement your own authentication system, as you would in any other hosting environment. Nothing about App Engine prevents you from doing so.
The Users API is just there as a convenience, in case you'd like to spare yourself the effort of re-implementing everything, and spare your users the inconvenience of filling out another sign up form and remembering another set of credentials.
You can always implement your own user management system.
In my application I have used spring-security for this purpose. spring security 3.0.1 works perfectly fine with app engine 1.3.5. There may occur some issues integrating other versions of both. I found below links extremely useful :
http://www.google-app-engine.com/blog/post/Spring-security-fix-for-google-app-engine.aspx.
http://www.dotnetguru2.org/bmarchesson/index.php?p=1100
http://groups.google.com/group/google-appengine-java/browse_thread/thread/964e7f5e42840d9c
We are starting a very large web based service project. We are trying to decide what hosting environment to use. We would really like to use Google App Engine for scalability reasons and to eliminate the need to deal with servers ourselves.
Secure logins/registrations is very important to us, as well as using our own domain. Our target audience is not very computer savvy. For this reason, we don't want to have the users have to sign up with OpenID as this can't be done within our site. We also do not want to force our customers to sign up with Google.
As far as I can see, I am out of luck. I am hoping to have a definite answer to this question. Can I have an encrypted login to our site accessed via our domain, without having to send the customers to another site for the login (OpenID/Google).
Thanks.
The hardest part is getting around the cookie issue. While you can do secure and custom logins against https://yourdomain.appspot.com, you cannot set a cookie there that will work on http://yourdomain.com.
Here is what I propose:
When you need to log the user in, send them to https://yourdomain.appspot.com. If they enter the credentials properly, create a one-time token and place it either in the datastore or in memcache. Give it a lifetime of a few seconds.
Then redirect the user back to http://yourdomain.com/authenticate?token=mytoken (obviously substitute the names as appropriate), check to make sure that the token is valid and has not expired, and if all is clear, set the appropriate cookies and expire the token.
I think that'd work just fine. Hope it helps!
As of June 27, 2012, App Engine supports SSL for custom domains.
http://googleappengine.blogspot.com/2012/06/google-app-engine-170-released-at.html
There is nothing stopping you from creating your own authentication/registration mechanism with Google App Engine. The only problem is that Google App Engine currently only supports HTTPS via https://yourid.appspot.com and not your Google Apps Domain (i.e. https://www.foobar.com). However, this is on the product roadmap for future support (SSL for third-party domains). Note, also on the product roadmap is built-in support for OAuth & OpenID.
Update: Another option may be to use a proxy server (like Apache with mod_proxy) and map your domain to the proxy server and then the proxy server can proxy the HTTP and HTTPS requests to Google App Engine. The requests could be proxied to the appspot.com domain behind the scenes. I haven't actually done this, but I believe it should work. However, this would give you a single point of failure at the proxy server which basically defeats the purpose of Google App Engine's high-availability and scalability. This would definitely just be a short-term solution until Google supports SSL for third-party domains or OpenID.
Depending on whether your threat model can accept a non-encrypted link on the "last hop" to GAE, you can use a proxy to handle SSL from the browser. Here's a HOWTO I wrote up on using CloudFlare to get always-on SSL:
http://blorn.com/post/20185054195/ssl-for-your-domain-on-google-app-engine
This isn't structurally any different than the way SSL from Google will work, it's just that Google-provided SSL will terminate within G's network rather than just outside it. If you're trying to protect against Firesheep, CloudFlare (or any other SSL proxy) will do fine. If you're worried about snoops on the trunk connection between CF and Google, you may want a more sophisticated solution.
I am still trying to wrap my mind around the workings of OAuth/OpenID, as such...
I am developing an "installed app" that will run on computers and iPhone. A given user may install the client app on multiple machines, and all of the user's installed clients will synchronize via a centralized Google App Engine service. The GAE service will also allow multiple users to collaborate on the data produced by the installed app, via a web app.
I don't want to roll my own authentication system, for my own ease and also to spare users from yet another set of credentials. As such I was initially thinking of using Google's clientlogin service, but then I thought OAuth/OpenID would be better because it would allow users to use not just Google credentials but also credentials from the other OpenID providers. Also, avoiding asking the user for a login/password seems more secure.
My question is... I'm not sure if this is the right use case for OAuth/OpenID. I am not accessing data from any other service, I am just looking for an authentication solution. Also, how difficult is this scenario to accomplish using Google App Engine (java)?
Any advice and/or starting points would be much appreciated!
My question is... I'm not sure if this is the right use case for OAuth/OpenID.
The "use case" for oAuth is: App X requires access to App Y. App X "asks" permission for access to App Y through your credentials. App X received an "authorized access token".
In your case, assuming I understood correctly, you could have the App on GAE implement an OpenID consumer and have your mobile app access the GAE app through oAuth.
In other words, your approach seems like a sensible one.