There is no way to do that unfortunately.
1 Like
I am stuck trying to make it work. Once Discourse has been approved access (//localhost:4000/oauth/authorize), and redirected back to specified URI with code and state params (//localhost:3000/auth/oauth2_basic/callback), Discourse fails to request token (//localhost:4000/oauth/token) as you can see in the snapshot below:
The OAuth2 provider is implemented using Doorkeeper, and both Server and Client are containerized with Docker.
I appreciate any idea about whatās going on.
This looks like a permission problem. Can you telnet into localhost:4000? You should post all your OAuth2 settings to help with debugging.
Itās not clear to me what grant type this supports. Eyeballing the code in some of the dependencies, it appears it might be the authorization code grant ( the flow where a code is provided on a redirect and exchanged for a access token.)
You are right, itās authorization code grant.
1 Like
The fact is that in order to get an auth code after user approval, Discourse makes a request to the same tcp port 4000 (//localhost:4000/oauth/authorize) without any issue, just before the ofending request for an access token. So indeed, Discourse container can reach port 4000 of the authorization server. All that said, which settings would be helpful with debugging?
1 Like
Hang on a minute, Iāll check my docker networking configuration.
It really seems like it must be a networking issue to me based on the error you posted.
I would enter the container and rails server and try something like open("http://localhost:4000").read and see if it connects. You might also want to try the difference between localhost and 127.0.0.1 which I have seen issues with too.
1 Like
Indeed, it was a networking issue. On one hand my rails authorization server runs on exposed port 4000 (4000:3000) inside a docker network created by docker compose. On the other hand Discourse runs on exposed port 3000 (3000:3000) inside default docker bridge network (as expected from scripts in ./bin/docker/*). They both are reachable on localhost:forwarded_port. Thatās why the first part of the flow of authorization code grant completes (I can approve Discourse). But then Discourse requests an access token to localhost:4000/oauth/token and fails, as no service is listening at port 4000 on Discourse container.
In order to make communication possible between containers, Iāve connected Discourse to my authorization serverās docker network, and after some tweaking of development urls via hotel, Iāve finally completed the full authorization flow.
These are my final configurations, they may help someone in similar scenarios:
Authorization Server
Client App
5 Likes
How does enabling this affect Sign up and the other Social Signup features? SSO disables them, does this do that as well? Or does it live with the other logins?
Iām not sure this is the right place to post this. If not, tell me and Iāll just try again in the proper category.
This is my user story:
Given Iām a registered and verified user on the resource server (authorization server),
and given I belong to some groups there that have counterparts in Discourse,
a) when I log into Discourse as a new user, Discourse should sign me up without asking me to do so, and should add me as member of those existing Discourse groups.
b) when I log into Disocurse as an existing user, Discourse should log me in and update my membership to groups when necessary.
The user endpoint not only provides the required information of username, userās full name and email, but it provides the collection of groups the user belongs to as well.
Now, I know that I need to develop a custom strategy to fulfill that user story, but Iāve got some questions Iād like to share before start coding:
Is it possible to implement this functionality as a plugin without touching Discourseās core code?
If so, would discourse-oauth2-basic be a good starting point to develop it? Is there any existing plugin I could use as a reference?
There is server side code and client side code involved in this user story. Any hints or guidance to start developing it?
Thanks in advance.
Why not simply use SSO here? It can add/remove people to and from groups and the flow only requires one click.
It not depends on me, oauth2 authentication is a requirement.
Then you are going to have to implement your own custom provider on Discourse end to build up the features you need, like passing through group membership from additional data in your oauth payload.
I know that. But having read some resources about plugin development in Discourse, I still have those doubts reported above.
Besides, Iāve inspected some oauth plugins code, and Iām not sure about what can and cannot be done using those hooks.
I am considering SSO as a temporary solution to my user story, while developing my own oauth2 custom provider. But before making any step further I need to know what the consequences would be. If I enable SSO for my user base to register and authenticate in Discourse, what necessary steps will I have to take when switching to OAuth2 authentication? What about external ids and any other persisted data?
we key on email, so you should be safe, you can also reach out to the SSO table if you need to from your provider if you need to cross check external ids.
I will give it a try. What about my concerns in my post above? Any advice?
Back again. Iām about to complete my custom provider as a Discourse plugin, but Iām stuck on one feature:
Once authenticated, I would like to auto create the user account if it does not exist. Some plugins like discourse-salesforce-auth, discourse-plugin-office365-auth and discourse-plugin-linkedin-auth use auto_create_account: true to initialize their auth provider authenticator, but I havenāt found any reference to this attribute in the Discourse code.
Any advice?
Just documenting here so folks looking to integrate discord logins to save some digging around their API. Thereās been a bit of interest around Discord, and I recently integrated Discord logins into my siteā¦ figured it wouldnāt hurt to share! 
oauth2 authorize url: https://discordapp.com/api/oauth2/authorize?scope=identify email
oauth2 token url: https://discordapp.com/api/oauth2/token
oauth2 user json url: https://discordapp.com/api/users/@me?token=:token
oauth2 json user id path: id
oauth2 json username path: username
oauth2 json email path: email
The scope are set as http parameters, space delimited in āscopeā. For oauth to login, youāll need identity (user info) and email (tack on email info in user payload).
This json url worked after some trial and error, using educated guesses.
Hope this helps someone!
7 Likes