I'm making an Android app that uses the Google Calendar API with a group of 3 other students, and we're struggling to understand the authentication process.
We expected to be able to be able to just include a Java library that calls the API and set our app to request calendar permissions, and then sign in to our personal Google accounts on our emulators and have the app be able to access our respective Calendars. We kept getting 403 (forbidden) errors, so obviously that didn't work.
So we tried to stumble through the confusing API documentation and copied some things from the Quickstart project. We managed to share the project with each other on the Google Developer Console and add OAuth credentials for each of our computers, and now it works for each of us, but we're still confused.
Why is this credential creation necessary?
How will the release process work? Obviously we don't want our users to have to generate SHA1 keys per-device to use our app from the Play Store.
Is there an easier way to do this? Do we even need the Developer Console?
These questions have likely already been answered, but I don't know enough about the process to know what to search for.
Google uses OAuth 2.0 for user authentication. What it means is that whenever a third party app requires permission to access Google's data, user has to first approve that request.
Now, to provide authorization Google provides you credentials (key & secret),Using this key & secret Google generates Access key and Refresh key to the application.
Access Key: Key used to access data from Google server for limited time.
Refresh Key: Key used to fetch new access key when older one expires.
Now focusing on your questions.
Q: Why is this credential creation necessary?
A: Credentials to assure that only your app can access user's calender data.
Q: How will the release process work? Obviously we don't want our users to have to generate SHA1 keys per-device to use our app from the Play Store.
A: Google will generate access and refresh key.
Q: Is there an easier way to do this? Do we even need the Developer Console?
A: Trust me..once you figure it out,it is very easy and most importantly secure way. (Google does not allow authentication using password as default)
You can learn more from here: https://developers.google.com/identity/protocols/OAuth2
Related
We at my company work with outsource on our Android application. If the outsource provider has the full source code, is it safe to also provide him with the certificate and its credentials we signing the application's APK with?
There are 3 steps of security for Android apps:
Source code
.jks and credentials
Google console access
If you break all three, they can rework and reupload your app to Google Play Store.
Probably, it's bad idea to send them .jks and credentials.
And actually, why do they need that?
The release keystore you use to sign a APK will remain the same across its lifetime. If you are using the App Signing system, sharing the upload key is less risky, since your Developer console account credentials will remain with you, and you can reset that key.
Even if they have full access to source code, it is better to limit access to certificates and keys in order to avoid impersonation or misuse later, when they may not be working with you. You may also consider managing permissions for developer account users to ensure they can only modify what you allow them to.
We are using Google Firebase to get CrashLytics data for our app, and the API key that is exposed through the google-services.json file was brought up as a security concern as the app apk file can be reverse engineered to get this file and then it can be used by an attacker to send data to our Firebase account.
To avoid this, we tried to follow this documentation to restrict the API key usage such that it can only be used by our app. This is achieved by restricting it with the package name and the SHA1 fingerprint of the keystore of our app.
However when we tested it out, it didn't work as expected. We were still able to send crash data via a fake app that has the same package name, same google-services.json file but a different keystore file.
Based on the accepted answer of this question, this approach should work. Appreciate it a lot if anyone with experience on this can share with us.
You have to go to https://console.developers.google.com/apis, and in your project credentials you'll see that your APIs are unrestricted. Follow the on-screen instructions on each API to restrict them.
I'm writing an app that requires a user sign in with Google on Android and then proceeds to get data from the server (a Google App Engine instance, in this case). How could I go about making sure that the user is actually logged in instead of just calling with a user ID? Is there a way for google to check a secure token they provide on Android for authenticity? Or is there another non-google related way to do this?
Thank you for the help!
Okay, so this is actually a very simple task. You ask Google Play Services for its OAuth Token and send that. Then the server asks Google about that token and Google will give it all of the information in the scope at once using one of their multiple limitless OAuth APIs.
I am using Android Licensing as described here:
http://developer.android.com/guide/market/licensing/index.html
(...to verify that my customers for my android app have actually payed for the app.) My app has a server component on the web, and for extra safety I'm doing the license validation on this server.
It all works okay. Now, to my problem. Since each new user ties up resources on my central server, I'm actually kind of reluctant to have non-paying users. I have seen some evidence of users continuing to use the app after having gotten a refund (per the normal 15-minute grace period).
To curb this behavior, it would be great if there was some way to map the payment of users at Google Checkout, to actual users in my system. Is this possible?
The ResponseData that I receive from the android license server contains a field called "userId", but this doesn't seem to correspond to any information in Google Checkout. (See http://www.androidadb.com/source/skylight1-read-only/GoogleLVL/src/com/android/vending/licensing/ResponseData.java.html for the definition of ResponseData.)
Is it possible to determine which payment in Checkout maps to which app installation?
As I currently understand it, the userId is obfuscated even on a per-app basis such that you can uniquely identify users per app but not figure which user it is nor whether the same user bought another app.
But I'm not sure you really need to identify these customers based on userId. If you have a server running anyway, the best way to protect your app is to have your server check the licence.
App -> Server: Give me a new nonce
Server -> App: Here is a secure random nonce
App -> Licence Service: Check user licence with this secure random nonce
Licence Service -> App: Signed licence response including repetition of nonce
App -> Server: Check licence signature with secret key (only on server)
Server -> App: Reject, or provide random token for access, etc
In this scenario, you won't authenticate users even if they mess with your LVL checking code.
However, you may of course introduce vulnerabilities after step 6 if you don't watch your step. Still, if you're currently using the standard LVL code and App-side licence check with the secret key stored in your app, changing to a mechanism as sketched above would be a huge improvement (there's even a script to remove standard LVL checking code from apps).
I'm creating an app that will need users to create an account. (Like Facebook or Twitter would require you to.)
BUT, since it's an Android app, should/can I let them sign in with their Google Account using AccountManager or some other service? It'd be very helpful if they could just sign in to their Google account and their settings and other options would be saved to that account.
Main questions summed up:
Is it possible to let a user just use their Google account in my app?
If so, do I use AccountManager to have them sign in and save account information/settings?
What are other options?
Yes, you can get users to log into their Google Services using their Google credentials, for example, I have an app on Google Tasks and I use the Android AccountManager to let users authenticate themselves using their Google account on the android device (No need for users to enter their password!)
There are some really good examples to get you started:
This is an in-depth look into how you can authenticate based on the users Android credentials, has an example of how things work and how the UI should be: http://www.finalconcept.com.au/article/view/android-account-manager-step-by-step-2
This is an example of getting AccountManager to work with a Google service like Google Tasks: https://developers.google.com/google-apps/tasks/oauth-and-tasks-on-android
The last example is using the same concept for accessing the Google Picasa service: http://code.google.com/p/google-api-java-client/wiki/AndroidAccountManager
The other options you have is to have users manually enter their username/password. For that you have to use a third party authentication API (like signpost for OAuth) for them to log in.
In my tasks/todo application I provide users both options to sign in, using their android credentials or using third party authentication for users that want to log in using some other account (an account which is not enabled on that device)
Let me know if you have more questions
Although it is a new development, Google Plus Sign-in introduced as part of Google Play Services can also be used. More info can be found at Android developers blog. See example implementation from Banjo app
There seems to be a big limitation - The user need to have Google+ app installed on the device to use this.
Also this is a pretty good blog if someone is interested in implementing the solution.
#Soham gave you some very useful links but he didn't correct one major error: AccountManager is the entity that manages the accounts on your Android device - it has nothing to do with your google account! you can use google account and create a NEW account on your device using the AccountManager.
The rest you can learn from the links Soham gave you.