I am building a service in which users do not have to create an account to sign up, but use Google account as exactly does Stackoverflow.com
My Question is there is any unique information of an user in OAuth2 which never change, so I can use it as user id in my database.
After looking through Google OAuth2 API, I've ended up that all tokens are arbitrary every time session is established.
I would like to know how such sites as Stackoverflow extract the user information to sign up.
After getting the initial access token use the tokeninfo endpoint to get user_id.
https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=" +
Uri.EscapeDataString(response.AccessToken))
Related
Account Linking provides several ways of linking users to their own accounts such as their Google account or Twitter account.
I chose OAuth in Actions on Google website to do OAuth 2.0 Authorization Code Grant for obtaining access token in exchange for data resources. When I linked a user to a Google account Google Sign-In enabled, the fetching of user information was easy because the data is stored under payload, but OAuth implementation does not seem like it produces user data under payload inside User object.
So should I make an API call to the third party to fetch the user data and store that personal data to a database in this case? I wondered if there is a way that Google prepares on behalf of developers. If not, then greeting a user who visits my app again by saying 'Hello, {person name}' gets tedious...
You have two options with Account Linking.
In the case you describe, you're providing an OAuth endpoint and getting an auth token from the Assistant, and you are responsible for taking this token and using it to determine who the user is so you can get whatever you know about him. The token is one that you issue and control, so presumably you have that info in your database already. If you are reusing a token from another service, that service should be able to tell you who they are.
It sounds like you're using using a Google Sign In, however, in which case it is easier to use Google Sign In for Assistant. Once the user has signed into your service (either through an app or webapp) and granted permission to your service, then they will also be able to gain access through the Assistant. You will get an id token which can be decoded to get profile information about the user including their Google ID and name.
I'm working on a web app where all users sign in using their Google account, using Google's OAuth2 API. I'm using ScribeJava to take care of the OAuth details.
I'm currently using the "sub" field of the user's ID token as their primary key in my database. When a new user logs in for the first time, their "sub" is stored for future logins.
I'm looking for a way for an administrator to add a user before they first log in - however, since I don't have the new user's "sub", I can't just add them to the database. Is there a way to use Google's API to look up another user's ID token (or at least the "sub" field) using their email address? Is there a better primary key that makes this easier?
Let me start by saying using the Sub id is probably a really good idea. However there is no way for you to get a users sub id from their email address. That information just isn't available until a user logs in as its part of the authentication Open Id connect claims.
Sorry but what you want to do isnt possible.
The task is simple. I want to use Sign In With Twitter as the user's credentials, allowing them to access restricted areas of the site and have their actions be associated with their account.
I am able to sign them in through Twitter. I get back an id, username, oauth tokens, secret tokens, ...
Now let's say the user then makes a site-specific action, like vote on a survey. I want to attribute the vote to their account.
What should I send to the server to prove that the vote is coming from the twitter user that it says it is?
For example, is it enough to send back the twitter id and the vote?
Can others get a hold of this id and then start making votes on the user's behalf?
Should I send twitter id, oauth tokens, and secret token to my server?
Again, how do I verify that these credentials are valid? Do the server need to make a call out to twitter to verify these credentials after every site-specific action? That seems excessive.
Do I have the server verify the credentials once and send back some random session key and then just verify the session key after each request for the remainder of the session?
This sort of thing has been implemented on thousands of sites, so just wondering what that common sense solution is. Sorry if this question has been asked before. In that case, reference to the answer would be greatly appreciated.
Also, I'm on node.js and using hello.js in case there's a stack-specific solution
Thanks
Your session key idea is fine. It will guarantee the association between further requests (e.g. Vote) and the Twitter user ID. The only problem if there is a man-in-the-middle then they capture the session key and can replay requests. This is solved by using HTTPS, which guarantees that no one has messed with an incoming request and hence guarantees the association with a user. And since the session key is short lived there is no chance they can be used in future attacks.
Does anyone have clues about how to do this? I'm basically trying to replace the strategy for "Connect With Google" from OpenID to OAuth. The challenge is identifying an old user (user on Google open ID) when a user signs in under the new OAuth scheme.
I have a working implementation which relies on email address as the primary key, as the open ID strategy captures that. The problem is, I don't want to ask for email in the OAuth flow. The ideal value is simply Google user ID, but the Open ID strategy doesn't seem to capture that.
So I have open ID tokens like https://www.google.com/accounts/o8/id?id=AfSCwGQ4PUaidXSQddJugXKLqU5V0MrXFhJM6UHybPw and trying to understand if I could get a Google ID from that.
UPDATE: I explained here how I ended up doing this migration - http://softwareas.com/migrating-user-accounts-from-google-openid-to-google-oauth-to-google-plus
We don't have a strategy ready today that avoids the user seeing another approval page.
However, rather than attempt to do an OAuth1 based hybrid flow and have to add all that legacy code to your server, I'd suggest you simply correlate on email address and move to OAuth2 login. I'm assuming you're like the majority of sites that end up asking for email address because they usually want it for account recovery. Just make sure you get the email address from OpenId as one of the signed parameters.
Then use the userinfo.email scope and OAuth2 https://developers.google.com/accounts/docs/OAuth2Login and you should be able to migrate with less developer pain.
In addition, we're in the process of adding support for OpenIDConnect and it supports a parameter of login_hint so you'd add &login_hint=bob#gmail.com to your authorization URL and it will steer the approval to the right account. This is not documented right now but it may be useful for you to try it. The user's browser could be logged into Google with a number of accounts and you want to try to get the right one. Always check the email you get from the OAuth2 flow to make sure it matches since this is just a 'hint'.
Users will still have to re-authorize for OAuth2, but we have plans to skip this reauthorization in the future. The main point is to plan on using OAuth2 and we hope to deliver a seamless migration soon and you'll be on a supported protocol.
Google uses directed identifiers for OpenID that are unique per relying party and are explicitly designed to conceal any correlatable identifier for the user. So the short answer is, no there's no way to get a Google ID that corresponds with a given Google OpenID.
One option, however, might be to use Google's OpenID+OAuth Hybrid flow. This allows you to get an OAuth token as part of a normal OpenID flow, which could then be used to get the user's ID from the OAuth2 Login API, which you can then associate with their existing account. Once you've done that for all of your existing users, then switch to using the OAuth2 Login directly.
The trick, of course, with this approach is getting all of your users to login again so that you can send them through the new flow. That will come down to how long you're willing to wait to migrate accounts, and whether you're willing to prod existing users by emailing them and asking them to login again (similar to a forced password reset).
In my application I retrieve OAuth token as per standard procedure. I know that the proper way to 'resolve' token to user information (including ID) is via:
https://graph.facebook.com/me?access_token=<token>
However this method appears to return 'false' for the so-called gray/advertising Facebook accounts. It so happens that I also need to deal with such accounts.
How can I retrieve user ID or any other useful user information for such accounts if the only information I have is OAuth access token? Should I resort to parsing the token to extract user ID a la http://benbiddington.wordpress.com/2010/04/23/facebook-graph-api-getting-access-tokens/ ?
Well, I still have no idea how to do it via Graph API.
Via 'legacy REST API' you can at least invoke this: users.getLoggedInUser
This will give you user ID (uid).