Email not present in IDToken from Google Auth - google-oauth

I'm trying to get the email from the IDToken returned by Google, this code has actually worked perfectly for months, until yesterday night.
Nothing was changed, and now for some devices, the Token doesn't contain the email.
I tried checking the OAuth2 playground for the same same accounts, and for all of them, the token provided by the playground actually has the email inside it.
On my phone, with the same account, it's not there.
I still get the name, account_id and stuff, only the email is missing.
On a colleague's phone, for the same account, the token contains the email.
The code for building the api client:
mGoogleApiClient = new GoogleApiClient.Builder(this)
.addApi(Plus.API)
.addScope(Plus.SCOPE_PLUS_LOGIN)
.addScope(Plus.SCOPE_PLUS_PROFILE)
.addScope(new Scope(Scopes.PROFILE))
.addScope(new Scope("email"))
.addConnectionCallbacks(this)
.addOnConnectionFailedListener(this)
.requestServerAuthCode(SERVER_ID, this)
.build();
If this was only my phone this wouldn't be so much of a problem, but the fact that it happens unpredictably on 1 phone means that it can't be relied upon.
I'd like to know if there's a 100% guaranteed way to make sure the IDToken will always contain the email.
Note: I tried the people.get endpoint, but it didn't fix this issue, and completely blocked some accounts from even receiving a token at all.

If you are requesting the email scope, email should be inside the idtoken. We definitely would like to debug the issue. Can you ping me with some information (through hangout) so we try to have a look?

Related

How do I change an ASP.NET Identity user's email WITHOUT requiring an email confirmation?

We have many non-tech-savvy users who find it very challenging to use the regular method of changing their email (click a link on the log-in page, enter their email, check their inbox, click the link in the email to confirm). We would like to allow the site admins to be able to change the emails directly, without requiring the users to do anything.
I realise that this has certain dangers, but we have checks in place to ensure that we are going to use the correct new email.
It seems that if I have the existing user from the database and the modified one from a <form> on the admin page, I can just do this...
existingUser.Email = modifiedUser.Email;
existingUser.NormalizedEmail = modifiedUser.Email.ToUpper();
existingUser.UserName = modifiedUser.Email;
existingUser.NormalizedUserName = modifiedUser.Email.ToUpper();
_appDbContext.Users.Update(existingUser);
await _appDbContext.SaveChangesAsync();
This does seem to work (with one caveat, see below), but given that I've never seen recommend this, and every example I've seen creates a token and uses UserManager.SetEmailAsync, I'm wondering if I've missed something.
The one caveat that makes me even more suspicious is that once or twice when I've tried the above, it's created a new user with the same details as the existing one, but the new email. I can't reproduce this, so can't say for definite what causes it.
Anyone able to comment on the best way to handle this? Thanks.
You can set and confirm the email without sending any email like this. Use the UserManager provided by ASP.NET Core Identity:
// set the email on the user, but don't send any email
await _userManager.SetEmailAsync(currentUser, newEmailAddress);
//generate an email confirmation token
var emailConfirmationToken = await _userManager.GenerateEmailConfirmationTokenAsync(existingUser);
//confirm the new email right away
result = await _userManager.ConfirmEmailAsync(existingUser, emailConfirmationToken);

What is the first parameter for Firebase.Auth.GoogleAuthProvider.GetCredential?

The new Firebase for Unity support has just been released into Beta and I am trying to implement Auth with it. I already have a Google sign-in that implements the oauth2 flow using an auth code from GooglePlayGames.PlayGamesPlatform.Instance.GetServerAuthCode and sending it to a server that exchanges it for an access token using the https://www.googleapis.com/oauth2/v4/token endpoint.
I assume this access token is the second parameter of the Firebase.Auth.GoogleAuthProvider.GetCredential method, but what is the ID Token that the first parameter is asking for? Is that the token obtained from GooglePlayGames.PlayGamesPlatform.Instance.GetIdToken (same as GoogleAuthUtil.GetToken, if my reading of the docs/code is correct)?
If this is the case, why are both required? I thought the access token was all that was needed to authenticate a user with google cloud services and that the ID Token was being phased out.
Edit: After some testing, I found that passing the ID Token obtained from GooglePlayGames.PlayGamesPlatform.Instance.GetIdToken does allow Firebase to authenticate. Problem is, it asks for the user's email address every time. I'd like to avoid this if possible.
What is the difference between GetToken, GetAccessToken and GetIdToken, aside from the fact that GetIdToken requires a callback?
I managed to "hack" this in order to get it working... But still i think the correct method should only be using GetServerAuthCode but I cannot make it work with that.
Do your normal process of getting idToken and AccessToken the first time, when you log in to firebase get the user's email and store it in playerprefs. Then the second time if you already have the email you do this:
AndroidJavaClass authUtil = new AndroidJavaClass("com.google.android.gms.auth.GoogleAuthUtil");
AndroidJavaClass unity = new AndroidJavaClass("com.unity3d.player.UnityPlayer");
AndroidJavaObject currentActivity = unity.GetStatic<AndroidJavaObject>("currentActivity");
string idToken = authUtil.CallStatic<string>("getToken", currentActivity, PlayerData.Email, "audience:server:client_id:XXXXXXXXXX-xxxxxxxxxxxxxx.apps.googleusercontent.com"); // your client id, should be a number a dash and then a bunch of numbers and letters
string accessToken = authUtil.CallStatic<string>("getToken", currentActivity, PlayerData.Email, "oauth2:https://www.googleapis.com/auth/plus.me");
Hope it helps although it would be greatif someone posts a solution with GetServerAuthCode cause that is the correct way

Authentication on Instagram to get the access_token using the API

I'm using the Instagram API and want to get the access_token in order to throw api requests over my own account. When I try to follow the first step and get the authorization code programmatically using RestTemplate I can't get it work.
String AUTHORIZE_URL = "https://api.instagram.com/oauth/authorize/?client_id=<CLIENT_ID>&redirect_uri=<REDIRECT_URI>&response_type=code";
String url = String.format(AUTHORIZE_URL, clientId, redirectUri);
String o = restTemplate.getForObject(url, String.class);
The response is the html code of the login page because Instagram requires the user to be logged in to check if the app is authorized (of course it is, since the app an the user belongs to my own account).
How can I authenticate before throwing that request so they return the code to my redirectUri and not complain about login?
Note: I tried simulating the request to their login form but it returned a 403 Forbidden.
NOTE: I already got a valid access_token, manually generated, and it works perfectly but I want to implement also a process to re-generate a new access_token automatically since they may invalidate it at any time in the future.
Even though our access tokens do not specify an expiration time, your app should handle the case that either the user revokes access, or Instagram expires the token after some period of time. If the token is no longer valid, API responses will contain an “error_type=OAuthAccessTokenError”. In this case you will need to re-authenticate the user to obtain a new valid token.
In other words: do not assume your access_token is valid forever.
Instagram is upgrading their APIs and the flows. Earlier we needed access token to bypass forced login screen. Since yesterday, they have removed that.
Now if you call this code, it will check if you are already logged in or not. If so, it will call the AUTHORIZE_URL of yours and will send a response code. The format will be either:
On success validation - http://your-redirect-uri?code=CODE
On error - http://your-redirect-uri?error=access_denied&error_reason=user_denied&error_description=The+user+denied+your+request
Now what I'm doing is I'm directly calling the above URL of yours every time. Now if the user is logged in, a response code will be sent to you, else user will be asked to login and validate your app and then the code will be sent. Technically, you are eliminating the possibility of the error case! So no need of overhead of storing access token in your database or verifying its validity.
Just try and check now what happens.
PS: If you want to check API behavior, simply type the URL on the browser and check what it returns! It helped me a lot while coding and debugging! :)

Twitter API - Reasons for "invalid or expired token"

What are the possible reasons that can cause token to become expired (besides having the user un-authorising the app)?
My problem is that I have an app with several thousands of users, all API communication works perfectly but for some users I am getting the invalid or expired token error, my initial though was that they are users who canceled the authentication to the app but I've contacted some of them and they haven't revoked the access.
Any ideas what other issues can cause that error?
Check the integrity of an access token at any time by calling the GET account/verify_credentials while using that access token.
Its mentioned and by research I came to know that:
Your access token will be invalid if a user explicitly rejects your
application from their settings or if a Twitter admin suspends your
application. If your application is suspended there will be a note on
your application page saying that it has been suspended.
Why is my twitter oauth access token invalid / expired ?
Check this post: invalid / expired access tokens.
There is one post in google groups that says:
You don't get a second chance, and this is by design. OAuth requests
have a unique signature; once a particular request is submitted, it
can't be submitted again.
If they enter the pin correctly, all is well, you get an access token.
If they enter the pin wrong, you get 401 Unauthorized - which is
expected.
But if they then try again to enter the pin, even the correct pin
shows as unauthorized.
Check this link for the above reference.
Some suggestions by twitter employee for the same problem:
I guess there are two things I would suggest at this point: 1.) Go to
your application settings and use the "Reset keys" tab to reset your
consumer key and secret, then update those values in the app and
verify that you still see the same behavior. 2.) Try passing
oauth_callback in your request_token call. Honestly I don't think this
will make a difference, but I want to try and be as rigorous as I can
here.
Also check this discussion saying:
You need to use the oauth_token and oauth_token_secret returned from
the oauth/access_token call instead of the one in your app's settings
in dev.twitter.com
I was getting same error then I changed (access_token) to (access_token_key) and it worked for me.
I hope it will help someone.
In addition to the comments everyone else has made, sometimes the twitter api will return a "invalid token" error when the token isn't the problem. I've noticed it the most when I've built a request string that doesn't parse correctly. For example, once I was getting that error when I was passing in screen_name's that had symbols that weren't URI-encodable. I also have gotten it when I passed in empty values like this (where the cursor is empty):
https://api.twitter.com/1/followers.json?cursor=&screen_name=whatevah
Could you give us the specifics of the calls that are returning this error?
Have you confirmed that the tokens worked at one time? In an OAuth system I worked on, there was an error in how tokens were securely stored and retrieved that caused a small percentage of them to become corrupted. If you can confirm that the tokens worked in the past, that's a good first step.
When you retrieve the tokens from storage, are they unchanged? Is it possible for them to get corrupted with the way you're managing them?
Put some logging in place to keep track of when tokens work and fail. Does a token ever start working again after it has failed once? If you fail to use a token for 30 days, does it expire? With a detailed log, you can start identifying the expired tokens and look for patterns in use to point to what might cause them to expire.
Be sure to explore other possibilities as well. How do users revoke tokens in Twitter? Is it easy to accidentally do that? For users with failed tokens, do they have other authorized apps that have stopped working as well?
First of all nice question Ran.
I want to ask you that have you gone through Twitter developers??
Sometimes it becomes ambiguous that which token to use since Twitter provides two pairs of tokens and the library.One of them is a secret key.
You need to select those token which starts with your Twitter ID followed by a hyphen.
Now your question is this error happens with some of yours users. So here is the answer that an app itself finds ambiguous to choose the token.
Though I might not be completely right, but I recommend you to try this solution at least once.
It might be possible these users have not revoked access. But in my experience an access token can also get expired after the user (in test cases: me) changed his/her password.
When the user does that, you can no longer use the REST API of stream API on that user's scope. Please adapt your application to handle with that situation. Revoke the user's session, so when he comes back to your application, he/she can be redirected to Twitter again to start a new OAuth access token process. Or send him/her an e-mail to kindly ask to reconnect. Vimeo/Windows/... are some of the people handling expired tokens with e-mails.
Have fun!
My God's answer is correct but I will share my answer from another question explaining how it could be your computer's clock:
If your OAuth flow was working one day and failing the next, check your computer's clock. I was running a Vagrant box that somehow had its time set to the day before, which caused the Twitter API to return {"code":89,"message":"Invalid or expired token."}. This may also appear as 401 timestamp out of bounds. You can use this command to update your clock in Ubuntu:
sudo ntpdate time.nist.gov
Alternative method if ntpdate isn't available on your system:
sudo date -s "$(wget -qSO- --max-redirect=0 google.com 2>&1 | grep Date: | cut -d' ' -f5-8)Z"
if your Access Token=738629462149844993-FcWHjfcucCLGEosyGGQ38qI******iC then don't forget to mention hyphen (-) followed by your USERID.
May be this will be helpful for you.I faced the same problem.
Please find the below piece of code snippet
$code = $tmhOAuth->user_request(array(
'method' => 'POST',
'url' => $tmhOAuth->url('oauth/access_token', ''),
'params' => array(
'oauth_verifier' => trim($params['oauth_verifier']),
)
));
if ($code == 200) {
$oauth_creds = $tmhOAuth->extract_params($tmhOAuth->response['response']);
// echo '<pre>';print_r($oauth_creds);exit;
$tmhOAuth->reconfigure(array_merge($tmhOAuth->config, array(
'token' => $oauth_creds['oauth_token'],
'secret' => $oauth_creds['oauth_token_secret'],
)));
$code = $tmhOAuth->user_request(array(
'url' => $tmhOAuth->url('1.1/account/verify_credentials')
));
}
The error invalid or expired token can be linked with the fact that one is not paying.
Without paying one will only be able to create the dev environment (sandbox).
As I have answered here:
Counts is only available to paid premium accounts, and one needs to pay for premium access.
Use this link to Apply for access.
Try to regenerate the keys again and save them properly.
For me, it happened because after regenerating one of the keys I did not update other keys. Therefore removed and regenerated all 4 keys again (CONSUMER_KEY, CONSUMER_SECRET, ACCESS_KEY, ACCESS_SECRET). And tried to execute it again and it worked this time.

How to make Foursquare App to be posting on connected users checkins?

So, I have my web app connected with Foursquare API up and running. It has it's own secret keys and everything. It listens to the incoming push notifications and trying to react on connected users's checkins. So far so good, however, when I'm trying to post something back on user's checkin via one of these:
checkins/reply
checkins/addpost
checkins/addcomment
I got 403 Forbidden error. I know, that I'm messed up something with OAuth tokens but I'm really stuck here and feel a bit puzzled. I try to summarize what's the current status and what I've tried so far:
I Have the App's: clientId, clientSecret, pushSecret
I also connected the Foursquare Account on which the app is creared into my web App, so I get the accessToken, let's name it: appAccessToken
Users are getting registered to my web app, so I get userAccessToken for one of each.
And here we go:
Trying to reply for a user's checkin fails when I'm using appAccessToken. From what I understand, it's like replying on behalf on my App's account, and since that account isn't on the user's "friend list", I get 403.
On the other hand, I'm able to post reply when I use userAccessToken but then, It looks like the user is commenting itself on their own checkins which dosn't have much sense.
I was even so desperate that tried to use clientSecret but no avail...
Can anyone point me out what am I doing wrong here? From what I understand from the Documentation it is, in fact, possible to reply as an App... The only question is, how? :-)
There's ostensibly no difference between the two "types" of access token you describe: appAccessToken and userAccessToken are really two instances of the same thing (a user's access token), one just happens to be associated with the user account that created the app.
For each check-in you are pushed, you should use that user's access token when making a call to checkins/reply. This will reply to the check-in in the style of our Apps Platform. I think in your second comment, you're using the user's access token to add a post to the check-in, which will make it look like the user is commenting on their own check-in.