I working for an app that requires google login. I need to access provider_uid, email, display name, first name, last name.
I managed to iterate all google accounts from the device and present them in a list. After the user perform a click on a list item, I access the selected account auth_token via AccountManagerCallback. But I need provier_uid(an example: https://www.google.com/accounts/o8/id?id=Alt....) and the fields enumerated above. I suppose I must perform some request to google server where to query this information (and passing account token key to request), but I didn't find any docs for this(only authentication, authorization - using ClientLogin, OAuth 2.0 and OpenId).
It's my first time when handling google auth(except picassa and yoututbe auth+upload).
I need this to update a database and be able to authenticate the user(which has the option to upload images and do other things on my server).
Thanks,
Alex.
I found a solution to this problem ( Webservice credentials - OpenID/Android AccountManager? - see Igor Zubchenok answer).
Now I send the auth token to my server where I use gdata/gauva jars to getter informations about the account.
Related
I have a collection of "Users" in Cloud Firestore and I am using Firebase Auth to authenticate my app users as follows:
The user authenticates within the mobile app (for example with Google).
I verify that there is no document within the "Users" collection that corresponds to the UID of the authenticated user.
If the document does not exist in "Users" I use the user's UID to create a new document.
It is my question: Is there a security problem with this model or some other type?
I am confused by Google documentation because it says that the user's UID is unique to the Firebase project but should not be used to authenticate my user to the backend server. It also says that in that case, I should use FirebaseUser.getToken () but that token can change, so it will create a new user in my DB.
So, my second question is: When should you use that token? Give me an example, please.
Thanks for the help.
USER_ID
You can use the google generated user_id for future reference. That will never change for a given user email or authentication type as long as the user is already in the database.
Example:
If the user Signed In with google federated login with user1#example.com then the user record is maintained in the Firebase and USER_ID(Say ABFDe12cdaa2...) will be assigned(You can use this id in URLs to see the user profile etc it is kind of 32 chars long(I am not sure exactly here). Now, If a user tries to sign up again with the same email(user1#example.com) then it pulls the previous record ABFDe12cdaa2.... If you delete a user1#example.com from the firebase database(Firebase maintains its own database of the user for your project, With has a limited number of user properties). Then the user tries to sign in again then the new USER_ID is generated.
Now the TOKEN:
As you USER_ID is public, it can be seen by everyone. It is not used for authentication.
So you need to generate the token( This is longer the user id) to authenticate programmatically with the Firebase. It token is temporary and specific to the user. It will expire in some time ( you can define that time while creating the token). a refresh token is used to get a new token.
I don't have any code examples while writing this answer. I will update with code example,If, I find any.
Hope I clarified some of your questions.
In android application, i am setting Cognito identity as follows:
Dataset dataset = ....syncClient.openOrCreateDataset("WHATEVER");
dataset.put("name", name);
dataset.put("email", email);
As a result Identity Id is created in this format:
us-east-1:1xxxxxx-999d-999x-NNNx-fxxxxxxxxxxx
The Identity Browser on AWS Web Console allows one to search only by Identity Id.
Now i want to search the identity by email (because that's all i know about the user). How can i search the identity by email in amazon web-console?
Alternatively, can i set email id as the Identity Id itself - if yes, how?
As of now, the only way to search an identity on the console is by identity id. We have heard the request from other customers to make it easier to search by another factor and will consider it in future updates to the service.
What you can possibly do to retrieve the identityId, is to write a Lambda function that will stored the email address of your user along with the identityId in a DynamoDB table when the Cognito Sync Event is fired.
Doing this you can then search in DynamoB using the user email address to retrieve the IdentityID of the player.
What you can do for now is store that id and the email in your own database somewhere via your own API if you don't want to add AWS services. Or do what pierre-leduc said
I have a simple RESTful backend and I am using HTTP Basic over HTTPS for authentication. It works fine, but I am looking for a appropriate solution to store the credentials (username + password).
There are a lot of examples out there and the majority suggest to use the Account Manager to store passwords. AFAIK the account manager stores only OAUTH (and similar) accounts and automatically generates tokens etc. But how can I use it to store and fetch the original passwords? Is it even possible?
Others suggest to store it as a hashed value, but this doesn't make sense to me (At the end of the day I will need to have access to the original string).
Sorry for another How to use HTTP basic and android question, but I was not able to find a suitable answer so far and to store the data within the local sqlite db as plaintext doesn't seem to be appropriate.
I have a few thoughts concerning your project/style of usrmanagement.
Why do you want to save the password on the device?
Why don't you work with auth tokens
Why not workig with the good old sharedPreferences.
I would suggest to do it like this.
At first register(no password and username are neccessary, it creates a user "Guest123") or login to the server with a password (hashed by the device, getting from a normal edittext from the user).
Then check for correctness on the server, if valid, send back an auth token and a time to live for that token.
Store this in the sharedpreferences.
Send the token with every request you make to the server, if this token is not valid (because time is over, logged in on another device...), tell the user.
There are couple of tweaks which could be done here, but for the beginning it shoul help ou on your project.
Of course you can use the Account Manager to store password as well. This is the method:
addAccountExplicitly (Account account, String password, Bundle userdata)
and you can get the password using this method:
getPassword(Account account)
There is a website with a lot of users. In order to use the private pages the user has to login with username and password.
Now I'm working on a android app that displays content from the website via an API in a native way, no WebView or similar. The workflow would be the following:
App is started
App checks if a sessionkey exists.
If the key exists, ask the website API if the sessionkey is valid and belongs to the user
=> if so, allow the usage of the app
If no sessionkey exists, ask for username+passwort, ask the API if it's correct and get a new sessionkey via the API => allow app usage
User clicks on e.g. "account balance"
-> API request is done with the stored sessionkey and the result is displayed
User clicks on "payout", fills in a form and gets his money
-> API request is done with the stored sessionkey and the result is displayed
Now I'm searching for a best practice solve for this. I don't want my sessionkeys to be simply hijack-able and I want to be sure that the sessionkey realy belongs to this user. As private data can be seen/modified via the app, privacy is important.
I took a look at oAuth but this isn't what I need I think because I need a consumer key and consumer secret that is unique for every user and I can't integrate this into the app. I don't want to have a new window/browser for entering username+password and handle the response via a callback like oAuth is doing.
Any hints on this?
Thanks a lot!
For a good starting point on http authentication best practices, have a look at this article:
"Principles for Standardized REST Authentication".
If you want to send private data, you need to use HTTPS. That will also take care of securing your session tokens, etc. If you need to check what token belongs to what user, you naturally need to have this mapping on the server side. Most server side platforms give you a session map or similar, keyed by session ID, etc. and you can store pretty much anything in it, including user details.
The Android docs say that its meant for "supplemental information about an order" but at the same time it also says not to use this to send "actual data or content".
So what is the purpose of this "developer payload"? Why does this feature exist? Can you describe a real-world practical example of how I can use it in my own In-app Billing implementation?
As aromero mentioned the developer payload field is limited in size. This is why the docs recommend not to use this key to send data or content.
What you do instead is save the content to a database somewhere (e.g. on the user's device or your own server), and then put the record's index in the developer payload field. When you receive it back via the PURCHASE_STATE_CHANGED broadcast intent, you can associate it with the data in your database.
Note that the developer payload is not sent by the Market when using any of the test android item ids. You have to be using real in app purchase items.
Also, according to this (I have not verified this yet), you will not be receiving the developerPayload in DEBUG MODE. You need to sign your application to RELEASE MODE to receive developerPayload.
Lastly, as you commented below, the returned JSONObject (in response to GetPurchaseInformation) already includes orderId, productId, purchaseTime and more. So "developer payload" should actually be used for anything but to identify the purchase... i.e. the answer is the opposite of what has been suggested below. What you can use "developer payload" is to add some information not in the JSONObject, like purchaser's additional details (e.g. GPS location if enabled, device brand & model, etc.).
The accepted answer is misleading and the last paragraph is plain wrong.
Here's what the official documentation has to say about it.
You should pass in a string token that helps your application to identify the user who made the purchase, so that you can later verify that this is a legitimate purchase by that user. For consumable items, you can use a randomly generated string, but for non-consumable items you should use a string that uniquely identifies the user.
When you get back the response from Google Play, make sure to verify that the developer payload string matches the token that you sent previously with the purchase request. As a further security precaution, you should perform the verification on your own secure server.
The payload may help you prevent to identify users who circumvented Google Play Service API or your app somehow by sending the payload to your server where you can check whether this user ever purchased the item. Presumably circumventing the GPS will get your app fooled with the purchase certificate. But if you have all the user IDs of people who actually did honestly purchase the item saved on your server - it would be easy to validate the purchase based on the user ID. The problem here - google made it impossible to rely on it unless you have all your users "logged in" in some way.
The docs provide a real example:
A developer-specified string that can be specified when you make a
REQUEST_PURCHASE request. This field is returned in the JSON string
that contains transaction information for an order. You can use this
key to send supplemental information with an order. For example, you
can use this key to send index keys with an order, which is useful if
you are using a database to store purchase information. We recommend
that you do not use this key to send data or content.
You can use this field to identify the item the user is purchasing. When you issue a REQUEST_PURCHASE request you can put additional information using DEVELOPER_PAYLOAD. When you get the response from PURCHASE_STATE_CHANGED you'll get this info back in the developerPayload field, so you can identify the order.
This field is limited to 256 chars and it's unencrypted (you can verify the signature though), it's not meant to store actual content.
I hope this will help:
Security Recommendation: When you send a purchase request, create a
String token that uniquely identifies this purchase request and
include this token in the developerPayload.You can use a randomly
generated string as the token. When you receive the purchase response
from Google Play, make sure to check the returned data signature, the
orderId, and the developerPayload String. For added security, you
should perform the checking on your own secure server. Make sure to
verify that the orderId is a unique value that you have not previously
processed, and the developerPayload String matches the token that you
sent previously with the purchase request.
More information here.