Some OAuth2 providers don’t provide email thus user have to fill the form to login. After filling out the signup form, a new user will be created and connected with this provider.
But that situation hurts when a user have been registered, it can’t connect with this OAuth2 provider.
In particular, a customer comes to me for building a integration with an external service for Discourse. Therefore, I am willing to have a way to let user connect with a Oauth2 provider in the user settings as well as an endpoint.
In the user setting, a pile of login method buttons will be shown after the email section. Existing association can have different style or status information.
But even admin panel can only show official oauth providers information (whether user registered with google, facebook, twitter, yahoo, github). So a little extension to inject for plugin authors is also needed.
Personally, I like this feature, it allows you to “glue” your account to multiple social login providers that use different emails addresses to your current one (or in the case of twitter supply nothing)
That said it is fairly tricky, cause if you allow to “associate” you must also allow to “disassociate”
I think “disassociate” means simply removed associate oauth uid and user_id in local.
One more problem is that oauth credentials can be expired. The provider may ask for re-authorization. (When a plugin author wants to use the oauth2 credentials to trigger API, they would like to know this situation)
According to those 2 problems, an Authenticator has to report association and expiration information. They are simply trying to find a user record implicit.
Now, Discourse has {google,facebook,github,instagram,twitter}_user_info. Plugins can use oauth2_user_info or PluginRow. I would say a new model can represent all those information, for instance:
uid, comes from provider
email
name
access_token
refresh_token
expired_at
CustomFields or a JSON field, can use for other information storage.
Then a simple query can get a list of associated providers for the user. Disassociation is simply done by remove this record.
Beyond that, Authenticator have to provide functions to determine:
A simpler implementation can also be illustrated as:
Adding 2 more functions for Authenticator which ask for revoking and querying association information. Plugin authors just need to take care of things by themselves.
The above post is a kind of refactor proposal to provide a generic interface.
But neither of them need changes for plugin authors if they don’t migrate to new API.
We’re looking into supporting Patreon OAuth login. This would be very good for that. Patreon isn’t really the sort of platform that you’ll naturally sign up to a site with, but you’ll definitely want to add it once you learn that connecting with your Patreon account can grant you some perks.
Same goes for Reddit’s OAuth, which doesn’t share emails.
Cool. It’s exactly what I want. But Patreon is kind of subset of my application. Could you elaborate the actual usage behind this?
My intention is to build a somewhat integration with Wechat public platform which is quite popular. This platform is too Chinese now so I’ll describe the scenario briefly.
Wechat user can subscribe a Subscription Account (SA later). Wechat allows SA provides tabs which redirects to a url.
Need: Know whether need to re-authorized based on token expiration; disassociate.
This is still a appealing way to implementation anyway. I could introduce fairly less interface changes in this way. Disassociates comes with a single boolean field which can show some hint for historical connection. Query only requires authenticator name & uid.
Using steam as an integration system for example, uses may register with an email address and then be unable to retain their previous account when logging in with steam. Having a feature that would allow people to link an account to their own, hence allowing them to use alternative methods of login as well as allowing other plugins to use this data would be useful in the overall scheme of things.
I was linked to this topic when I had similar questions / ideas in a topic I posted.
After reading it however, it doesn’t appear that much happened after the idea was discussed in April 2016.
The idea of having accounts where an external provider can be associated and disassociated from an account is one I like as a Discourse Admin* and as a user of various Discourse powered forums.
I’m curious if there has been any progress on implementing this idea in the nearly two years since this topic was posted.
* Discourse Admin Note: Thus far I have wanted to use Discourse as a forum for a personal web site but have not got around to finishing the setup of it and am the only user in my current Discourse forum.
It’s something we’ll probably do at some point, but it’s not on any immediate roadmap. It’s a very useful feature for those rare times that you need it, but it is not so critical (there are usually acceptable workarounds like logging out and logging back in with a new provider) that it’s high up on anyone’s list.
