Simple question. If I use Google authentication and someone else (not related to my project in any way) authenticates the same Google account, does my and their ID token contain the same "sub" claim?
So I registered two different apps under two different Google accounts and it seems that the "sub" claim is identical.
So the answer is "yes".
Related
Probably a long shot, but after authenticating a user via OAuth and retrieving some user info from the provider, is there a way to prove to a third party that this user is authenticated and that this piece of information retrieved with the token (an email address, for example) is indeed the data supplied by that provider? Without sharing the access token, of course.
Primarily interested in Google and Facebook here, if that makes a difference.
The general, standard way is to use OAuth2 Introspection.
Not everyone supports this (I don't know of any of your 3 providers do). Potentially a good fallback could be to just do a request and see if it succeeds.
I'm trying to work out how to structure a database schema that allows me to have multiple authentication sources for the same end-user.
For example, my web app would require users to sign in to utilize many of the functionality of features of the app. However, I do not want to be responsible for storing and authenticating user passwords.
I would like to outsource this responsibility to Google, Facebook, Twitter and similar identity providers.
So I would still need a database table of users, but no column for a password. However, these are authenticated would not be my concern. But I would still need to somehow associate my user with the identity providers user id. For example, if my user signs up with Google, I would store the users Google ID and associate this with my user. Meaning next time the user makes an attempt to login and is successfully authenticated at Google, I would make an attempt to find any user in my system that has this associated user id.
I've been trying to look for some common and recommended database structures, with no luck. Maybe I'm searching for the wrong terms for this because I cannot imagine that this is an uncommon way to do it. StackOverflow seems to do something similar.
The way I imagine it, it would allow me to associated multiple authentication sources for one app user. Meaning once I've signed up with Google, I can go to my settings and associate another account, for example, a Facebook account.
How should I go about achieving this in a flexible and clean way?
Thanks.
You need to know what data you have to save in your db to authenticate a user with a third party login.
For example, once I used Google to login users in my app, I save Google user id first time a user logs in and get data the next time.
You could have an entity with third party providers, so you will create a table with 2 values, user_id (your user data) and provider_id (Google, facebook, twitter...).
If you are going to use just one provider then you could add provider_id field to your users table.
I doing research about OAuth2. A lot of things are clear for me but I have 2 questions.
Question 1, client_id, and client_secret
With OAuth an client can be identified with the client_id and client_secret.
But I cann't find the difference between these 2. I only found that the client_id is public and the client_secret is private.
I think it works like this but I'm not sure about it.
*When there is an app called "GreatApp" which would to get data from the OAuth2 API. It registers by the API and it gets 2 id's one client_id which is the same for every individual installation of the GreatApp. And they get the client_secret which is unique for each individual installation of the GreatApp.
This means you can recognize the application which connects to the API with the client_id and you can recognize an individual phone or tablet by the client_secret.
Is this correct or am I wrong?
Second question: Different types of flows
There are more than one kind of flow used by OAuth2. I read a lot about this and watched some videos on YouTube. They explain 2 or 3 kinds but they don't say clearly the name of each flow. I Googled a lot but I can't find a clear explanation about what type of flows there are and which I should use in what situation.
I found this documentation but this is Oracle-specific I think.**
Is there someone who can explain to me the flows and when I should use which flow?
Client ids and secrets are used for confidential clients, meaning those that can keep a secret such as web applications that live on web servers. They are typically not used to register individual instances like mobile apps.
Which grant flow to use when I've described in this answer. HTH
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).
I assume workflow for OAuth is very similar in various sites. (twitter, linkedin)
I can successfully get requestToken, accessToken.
Is it okay, if I just store Accesstoken and use it later???
Yes, this is the generally accepted practice. I use this workflow on a few sites and based on the posts on the LinkedIn Developer's site, it looks like the method that most people are using.
The only trick is to cover yourself in the case that the user rejects your application's access rights; filter all responses from the LinkedIn API looking for an error indicating that the access token is no longer valid (you should be doing this filtering anyways for throttling issues).