I’m looking to build an independent website for a Patreon content creator. We would like to use Patreon as a gateway for authenticating new users who would like to interact with the website; i.e. you can log onto the website and participate in certain features if you have a Patreon account. Certain aspects of the website we will have for Patrons-only, but other areas we want to make available for anyone with a Patreon account. On the OAuth access token grant stage we plan on either creating a new account in our local DB based on the user’s email, or logging them in if we have their email address recorded.
The documentation however states “don’t use Patreon OAuth as the primary login mechanism for your site”. Could you please explain why this is the case? As far as I can tell it uses the same OAuth protocol that at “Sign in with Google” or Auth0 button would use. Would the use case I cited above be an acceptable use of the Patreon API?
Clarification on this security warning would be much appreciated. Thanks.
While many people are familiar with OAuth from things like “Login with Facebook”, it’s important to note that Patreons Implementation of OAuth is not intended to serve as an authentication layer for third party services, but rather as a way to “Connect” one’s Patreon user details to a preexisting account on third party services.
Restated simply, don’t use Patreon OAuth as the primary login mechanism for your site, only as a way to Connect a users Patreon profile to a user profile on your site. Doing otherwise will create very serious security vulnerabilities on your site.
I don’t think that statement is particularly fair. Although true that OAuth is not an authentication protocol, it is used that way by most popular implementations and the common attack vectors are dealt with by any sensible OAuth server. The Patreon OAuth server requires whitelisting of redirect URIs, it supports passing state to prevent CSRF attacks, and each authorization_code is bound to a client to prevent injection attacks: the very serious security vulnerabilities are mitigated.
I suspect that statement was written when the Patreon platform was brand new and didn’t have any of the attack vectors mitigated, and hasn’t been updated since. Alternatively, whoever wrote that statement is an OAuth purist… but in that case everything is about compromise. This is much like writing “Accepting user input will create very serious security vulnerabilities”. That’s absolutely true, user input can cause all sorts of issues, but you can mitigate those issues with tried and true methods. Sure, in an ideal world you would never accept user input because it’s an attack vector but in the real world you probably need to accept user input… so you compromise and accept it, with the appropriate mitigations.
I’m not a security professional so perhaps there’s an aspect of this that I’m missing and I am happy to be corrected but based on the typical OAuth attack vectors (which you can read about in various blogs), and the fact that they’re mitigated by the Patreon OAuth server, I am pretty confident in suggesting you can use Patreon as your primary login mechanism without exposing yourself to major security vulnerabilities.
You can read more about OAuth not being an authentication protocol on the OAuth website, which covers aforementioned security vulnerabilities: End User Authentication with OAuth 2.0 — OAuth
Thanks for the response. Sounds like that was written in the early beta stages of the API and maybe the dev team lacked confidence in the protocol. Really it doesn’t seem any different than using Sign in using Facebook or Google.
I think making Patreon a gateway to access a site is a terrific way of making it known to users that the content creator has a Patreon account and thereby encourage donations.
Hey folks,
Chiming in here as a member of the platform team. First off, huge thanks for all of your wonderful support on this forum Sam. You’ve become a local hero here at Patreon.
I think I can speak to the security vulnerability mentioned in the docs. The biggest issue is using Patreon as an authentication system alongside another auth system, using the email as the unique identifier. The reason for this is we do not currently require users to confirm their email when signing up for Patreon (there are a few reasons for this that are out of scope for this response). So essentially, it would allow any person to make an account on Patreon with any email address and use that Patreon account to take over the users account with the email on your website. As an example, say you have a user "elon@musk.com" and they typically log in with their email and password. Then some malicious person that wants to take over their account registers "elon@musk.com" on patreon and then clicks the login with patreon button on your site. Your code looks at the email and assumes it must be the real "elon@musk.com" and auths them in. Now the hacker has control of that account.
I hope that explains our concern more clearly. For the time being, this is not something we plan to change (mostly because asking for email confirmation would dramatically effect pledge conversion and hurt creators bottom line, ultimately we are here to get creators paid not add friction to their funnel)
Happy to answer any more questions about this.
Cheers!
-Spencer
Thank you for the further details on this vulnerability! How do you recommend overcoming this issue? Have an email confirmation on behalf of our site?
If someone’s email address is “stolen” by an imposter using it to make a Patreon account, what can the person who actually owns the email address do to rightfully claim the account?
I spoke with the team in a bit more detail about this question. Our stance is that you should generally be ok implementing authentication as long as you don’t map and merge the emails with preexisting account. That’s the biggest vulnerability. If you’re just creating new accounts on your site for patreon authenticated users, or you are allowing users that are already signed in to “connect” their accounts which can be used for authentication later, that should be fine.