0

I understand what oauth2 is and I've programmed it in one of our projects. The point was to pull user's data from an oauth2 provider (facebook, google, etc.) to our application (for example, the user's 10 most recent emails). It was very handy for that purpose.

Now I'm trying to think about why a web designer would want to include oauth2 as a means of logging into their site. I can see it being useful for a free website. If the user doesn't want to create their own account with the site, they can simply leverage an already existing account with an oauth2 provider (facebook, google, etc.). They would simply log into the oauth2 provider, get redirected back to the website with the access token, and use that access token to get around the site. So the site essentially "shares" the access token between itself and the oauth2 provider (like saying: so long as you're logged into facebook, you're also logged into our site).

But what about a site that requires a paid subscription to log in. In that case, you wouldn't want the user to log in using some other oauth2 provider. That would allow the user to bypass signing up for a subscription. I guess you could send a request to the oauth2 provider (once you have the access token) for the user's information, match it with something in the website's database that indicates the user has signed up for a paid subscription, and if a match is found, proceed with the login. Otherwise, deny access. If access is denied, redirect the user to sign up for a subscription. But is oauth2 login ever used this way?

If oauth2 login is used by sites that required a paid subscription to become a member, how does it work? How does Facebook, for example, know that you've signed up for a subscription on a client app's site and therefore grant you the access token? Or does it work the way I described about?

6
  • 2
    Oauth doesn't bypass billing. Facebook doesn't care if your site requires payment to see content, and an access token doesn't automatically mean you get to see all the content on a site. It's a means of authentication not of authorization.
    – Kayaman
    Commented Jun 19, 2019 at 4:38
  • That's what I figured. But how do most sites handle that? Say I go to mysite.com, which requires a paid subscription to log into. I haven't sign up for an account. I'm offered the option of logging in with facebook. I log in with facebook, it returns to mysite.com with an access token... then what?
    – gib65
    Commented Jun 19, 2019 at 4:48
  • 2
    It's basically the same as if you were to register with a username / password. You need additional information to determine whether that user has a paid subscription, whether the user is an admin, etc. If a user has logged in with any kind of method, it only tells you that the user has a right to log in. All additional logic needs further data linked to that user. Here the user is just identified with the oauth token instead of a username. The advantage is that people don't need to remember different usernames / passwords, so it makes it easier to register in the first place.
    – Kayaman
    Commented Jun 19, 2019 at 6:59
  • Thanks Kayaman, this confirms what I thought. I'm going to try an experiment. I'm going to sign up for a spotify account with completely different information from my facebook account (different name, email, etc.). Then I'm going to try to log in with facebook and see what happens.
    – gib65
    Commented Jun 19, 2019 at 7:21
  • 1
    "Sign in with Facebook" is an alternative to passwords (i.e. log-in credentials). It is not an alternative mechanism to implement accounts. OAuth may also allow you use some APIs of the OAuth provider, but that is orthogonal to log-in. The data in the account doesn't have to match the data on Facebook, the accounts just need to be linked.
    – amon
    Commented Jun 19, 2019 at 8:21

1 Answer 1

3

You are - to some extent - mixing up the concepts of Authentication and Authorization.

Authentication [...] is the act of confirming the truth of an attribute of a single piece of data claimed true by an entity. (Wikipedia)

Basically, the OAuth2 provider confirms that a user is who they claim they are without the need to tell you details you don't have to know (like their password for the OAuth2 provider).

Anyway, this is completely independent from any plans, billing or whatsoever related to your service.

On the other hand:

Authorization is the function of specifying access rights/privileges to resources

This is completely independent from the OAuth2 authorization. You'll have to make sure that only users who have paid are allowed to access your services (resources), or parts of it that are restricted to premium users.

How you implement this is completely up to you and sorta depends on your business needs, UX considerations, etc. Anyway, you could - for example - check when a user logs in whether there is an active plan. If not, the user would be redirected to a payment page where they can pay for a plan. When they have paid, you store that information in your database and grant the user the rights to access the restricted resources.

3
  • 1
    Thank you for that answer, Paul. That's exactly what I wanted to know. There would have to be some common information shared between the oauth2 provider and mywebsite.com (like an email or a facebook ID) in order to associate the oauth2 token with the mywebsite.com plan. This is not guaranteed to always be the case. The user could pay for an account at mywebsite.com with a totally different name, email address, username, etc. than anything stored with their facebook account. If they didn't login with facebook before signing up, they couldn't use facebook to login on future occasions.
    – gib65
    Commented Jun 19, 2019 at 7:14
  • 1
    @gib65: Yes, that is guaranteed to always be the case because it's up to you to ensure it. OAuth is only a solution to authenticate users, it's not a complete account management solution. The scenario you're describing is equivalent to someone simply creating two separate user accounts without OAuth, you wouldn't expect those to share a subscription either, would you? Commented Jun 19, 2019 at 8:48
  • Thanks for the input Michael. I don't understand how it can be guaranteed. Suppose they signed up for an account at mysite.com, using email [email protected]. Next time they visit my site, they authenticate with facebook. Their email registered at facebook is [email protected]. Facebook returns a token. How can I use that token to figure out which account belongs to them on mysite.com? I can't look for matching emails even if I wanted to request their email from facebook. What if NONE of the information I could request from facebook matches what they have in their mysite.com account?
    – gib65
    Commented Jun 20, 2019 at 1:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.