Question

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?

Was it helpful?

Solution

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.

Licensed under: CC-BY-SA with attribution
scroll top