Is there some way a user can set a custom identifier so we can identify them on our site? I realise their email address is exposed by Patreon but we cannot use any personally-identifiable information such as this. We would need patreons to set a custom flag on their account so we can identify them… is there any provision for a feature such as this?
What’s your use case, can you talk more about what you’re trying to achieve and any limitations you need to work within? If I understand your question correctly, you may be approaching OAuth from the wrong angle.
When using OAuth you delegate the responsibility for authorization to the authentication provider but you are responsible for identifying users within your own service, and if you need more information about your user than what is available via the authentication providers API then you must collect and store that information yourself. Almost all OAuth consumers will use an authentication provider only for authentication and will have their own local database that persists user information.
Patreon provides a unique identifier (“id”) for each user which you can use to identify users in your own system. Here’s an example User Resource:
{
"data":{
"attributes":{ ... },
"id":"1",
"relationships":{ ... },
"type":"user"
},
"links":{
"self":"https://www.patreon.com/api/user/1"
}
}
If you needed a custom identifier for a user (e.g: a username) you could do something like:
- A user clicks “Log in with Patreon” and completes the log in flow
- Your service receives an access token
- You make a request to the
/current_userendpoint, with the access token, and receive a User Resource - You extract the user’s ID from the Resource –
data.id - You display a form asking the user to provide their chosen custom identifier
- You validate (based on your own rules) and store the user’s custom identifier along with their Patreon User ID
- Anytime you need to output their custom identifier, you do a lookup in your database against their Patreon ID.
Something to note is that there is already a unique public property (vanity) which refers to their URL fragment, e.g: patreon.com/vanity, however, this is an optional property (can be null) and because it’s a mutable property you would run into issues with people who have changed their vanity (and then it’s picked up by another user).
1 Like
My site is static; it has no database backend and no persistent storage. When a user signs in with OpenID we will get nothing but a public identifier for that user. We need some way to determine if that identifier matches a patreon, but it won’t, unless they have some way of linking that third-party service to Patreon, which I suggest would be accomplished with a custom field… but I suppose we could scrape a description field from their bio or something instead, but that’s not ideal.
To be clear, I do not want users to have to sign in with Patreon at all. Since they already have to sign in to another third-party service, I’d rather just have one thing for them to sign into, if possible.
I’m not clear on the way that your website works so I apologise if I’m off base but based on the information you’ve provided I think you’re authenticating users with another provider and then you’re pulling in pledges for a Patreon Campaign and trying to identify which (if any) Pledge is from that user to [do something], is that correct?
The approach you’re thinking about – having Patreon store custom metadata on a Pledge for you, to help you associate a Pledge with your third-party provider user data – would work but it would increase the amount of work both Patreon and your application are responsible for. Patreon would need to persist metadata, and your application would need to keep Patreon in sync.
Although it’s not a great user experience for a user to have to authenticate with multiple services to access the functionality of your website, it’s the correct approach if you’re unable to persist any data – although, even if your site doesn’t have access to a local persistence layer, there are options like Firebase – and even if Patreon could persist Pledge metadata for you, you’d still need to perform an initial authentication for the user.
2 Likes
Yes, you have understood correctly, despite my somewhat incoherent rambling, so thank you for that!
Why would I need to keep Patron “in sync”? Surely a pledge is good for at least one month, so I shouldn’t need to check again for another month after a successful auth, correct? I was thinking the auth data could just be stored in localStorage. Maybe I’m overlooking some of the finer details.
I don’t know the specifics of the third party service you’re using so it’s possible in your use case you’d only need to set the third party provider id once in the (hypothetical) Pledge metadata, I was imagining a situation in which the third party account could change and the user would want to associate their Pledge with a different account, which would require you keep the metadata in sync because you would be offering disassociation functionality rather than just set it once on initial login.
Pledges can be deleted, edited, refunded etc. but assuming your system is working as I described previously then that’s not a concern because on each login you would be iterating through all Pledges to identify which belongs to the user, so at login you’d have the most up to date information on their eligibility for access to the website.
Right, but does Patreon even have this metadata functionality or not? If so, can I find its documentation somewhere?
Sorry for any confusion: as far as I know, it does not offer any such functionality. I was saying that functionality would be needed for your approach to work, and why I don’t think it would be the correct approach – although I am just an API consumer like you, maybe the Patreon team will want to implement it.
1 Like
Patreon returns User id of the user at Patreon i believe. This is a unique identifier for the user in regard to patreon. This can safely be used.
Thanks so much for your help and insight, sam! I actually guessed you must be an employee. I’m so lucky you have such time to spare for me.
1 Like