OAuth Server

[wohali]

This is the support topic for the OAuth Server application.

This application adds an OAuth2 server to your IPS Community Suite 4 installation. This allows external applications to authenticate and authorize against your IPS4 membership.

Administrators looking to integrate external applications with their IPS4 site via OAuth2 can register those applications with the IPS4 Admin Control Panel (ACP).

Permissions can be set to allow only certain specific user groups to use the OAuth gateway.

The source code is public (GPLv2 license) at https://github.com/wohali/ips4-oauth2-server. Pull requests and issues are welcome. issues and questions can also be posted to this support thread.

Installation

1. Download the latest version of OAuth2 Server for IPS4.
2. Unzip the archive and locate the oauth2server.tar file.
3. Navigate to your site's Application list (ACP > System > Site Features > Applications).
4. Click the Install button and upload the oauth2server.tar file.

Application configuration

1. Visit the settings panel under ACP > Community > OAuth2 Server > Applications.
2. Click the Add Application button.
3. Enter your application's name and its Redirect URI. The Redirect URI is typically found in your application's OAuth settings or documentation.
4. Click Save.
5. Select the user groups you wish to be able to authenticate and authorize
6. At the list of Applications, click on the Edit pencil.
7. Take note of the application's Client ID, Client Secret, and Authorization, Access Token, and Profile URLs. Your application will need all of these values to complete its OAuth configuration.

 

I'd like to encourage anyone who uses this application to integrate IPS4 with another app to post in this thread, and show any configuration steps you had to go through. I'll be following up to this post with another showing how to use OAuth Server to integrate IPS4 with Rocket.Chat.

 

 

[Joel R]

I'm not using but thank you for offering this resource to the IPS community.  

[wohali]

Here's how to configure the OAuth Server application to integrate IPS4 with Rocket.Chat.

Rocket.Chat

1. Install and setup Rocket.Chat. A walkthrough is beyond the scope of this guide.
2. Create an initial administrator user and password, then login as that administrator.
3. Administration > OAuth > Add Custom OAuth button (at the very bottom). Enter a unique identifier for this integration (ex: ips4)
4. Find the Custom OAuth: <IPS4> section and expand it. Make a note of the Callback URL, e.g. https://your.rocketchat.com/_oauth/ips4 

IPS4 Site

1. ACP > Community > OAuth Server > Applications > Add Application.
2. Enter a unique name for the integration (e.g. Rocket.Chat) and the Callback URL you obtained from Rocket.Chat above.
3. Click Save.
4. Select the user groups you wish to be able to authenticate against IPS4 for this integration. Do not select Guest!
5. Click Save.
6. Click on the Edit pencil again and take note of the Client ID, Client Secret, and 3 integration URLs.

Rocket.Chat

1. Change the following settings:
   Enabled: True
   URL: Top-level URL for your IPS4 site, such as https://your.ips4.com/. If your site is not installed at the root of the webserver, include any subdirectory here, such as https://mysite.com/ips4.
   Token Path: applications/oauth2server/interface/token.php
   Identity Path: applications/oauth2server/interface/me.php
   Authorization Path: applications/oauth2server/interface/authorize.php
   Token sent via: Payload or Header both work, it doesn't matter.
   ID: your Client ID from IPS4 here
   Secret: your Client Secret from IPS4 here
   Login Style: I recommend Popup
   Button settings as you wish.
2. You may have to restart the Rocket.Chat server at this point. I had to, but I cannot guarantee that is is mandatory.
3. Logout as Administrator and use the new button to log in as an IPS4 user.
4. Log back in as the Administrator user and give admin access to your IPS4 user (#general chat > people icon on the right > click on user > MAKE ADMIN).
5. (Optional) Disable username/password login for Rocket.Chat: Administration > Accounts > Show Form-based Login set to False. WARNING: Do not do this until you have made at least one IPS4 user an administrator or you will lose admin access to your Rocket.Chat server!

Please post in this thread if you were able to follow these instructions to integrate your Rocket.Chat server with IPS4!

[wohali]

I've just released v1.0.1 that fixes a problem with the cleanup task setup (invalid name) and adds a CSRF token check to the authorization form for added security.

[Taylor M.]

sure its been asked before and i apologize can this be used for discord?

[wohali]

No, Discord only acts as an OAuth Server itself. It cannot be configured to act as an OAuth client in which the Discord server takes authentication and authorization information from an external source (like IPS4).

[RevengeFNF]

On 30/05/2016 at 0:31 AM, wohali said:

Here's how to configure the OAuth Server application to integrate IPS4 with Rocket.Chat.

Please post in this thread if you were able to follow these instructions to integrate your Rocket.Chat server with IPS4!

Thanks for this tut. Worked 100% 

[Ohio Riders]

I'm trying to set this up with Rocket.chat. The login button is there on the Rocket.chat login, but when I click on it I just get a popup with the forum home page. No login form or auth form, nothing. Thoughts? If I close the window, I get an error saying "no matching login attempt found". Thanks. 

[wohali]

{"error":"invalid_client","error_description":"The client id supplied is invalid"}

1 hour ago, Ohio Riders said:

I'm trying to set this up with Rocket.chat. The login button is there on the Rocket.chat login, but when I click on it I just get a popup with the forum home page. No login form or auth form, nothing. Thoughts? If I close the window, I get an error saying "no matching login attempt found". Thanks. 

Are you already logged into the forum when this happens or not?

If you're already logged in, the ref=### redirect is not working, which means you may have entered the authorization URL into Rocket.Chat incorrectly. Double check that you are using the correct protocol for the URL (http or https, I have tested both) and that the URL entered directly into a browser correctly brings up the authorization page (assuming you are logged in).

For example, on my website, when not logged in, I enter https://<mysite.address>/application/oauth2server/interface/authorize.php and I am redirected to a login page. After logging in, I get back the response:

{"error":"invalid_client","error_description":"The client id supplied is invalid"}

This is what you should be seeing.

[Ohio Riders]

2 hours ago, wohali said:

{"error":"invalid_client","error_description":"The client id supplied is invalid"}

Are you already logged into the forum when this happens or not?

If you're already logged in, the ref=### redirect is not working, which means you may have entered the authorization URL into Rocket.Chat incorrectly. Double check that you are using the correct protocol for the URL (http or https, I have tested both) and that the URL entered directly into a browser correctly brings up the authorization page (assuming you are logged in).

For example, on my website, when not logged in, I enter https://<mysite.address>/application/oauth2server/interface/authorize.php and I am redirected to a login page. After logging in, I get back the response:

{"error":"invalid_client","error_description":"The client id supplied is invalid"}

This is what you should be seeing.

It was actually an issue with the Nginx config. I have it pretty well locked down. It wasn't allowing the /oauth/authorize after authorize.php. I added this to get it to work:

    # rocketchat oauth
     location ~^(/applications/oauth2server/interface/authorize.php/oauth/authorize).*$ {
        fastcgi_pass   unix:/var/run/php-fpm/ohioriders.sock;
        fastcgi_index  index.php;
        fastcgi_buffers 16 8k;
        fastcgi_buffer_size 16k;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        include        /etc/nginx/fastcgi_params;
    }

Now I have a few more questions/issues if you don't mind.

 

1) The name and user fields are auto populated. However, a user could change either/both to whatever they wanted. Is there a way to lock it down so the name/user cannot be changed from what comes from OAuth? 

 

2) While the me.php pulls the avatar, it is not used in Rocket.chat. Is this by design or an issue? I checked the Nginx access logs to get a me.php request with token. This is the output:

{"id":8610,"username":"Casper","displayName":"Casper","email":"removed","profileUrl":"https:\/\/ohioriders.net\/index.php?\/profile\/8610-casper\/","avatar":"https:\/\/ohioriders.net\/uploads\/monthly_2016_07\/13307303_10101184598627157_6894574089523939806_n.jpg.c7134d2837e820c6aab899bbd412bd91.jpg"}

The URL for the image is correct. 

 

3) What happens when a username change happens within IPB? If avatars are supposed to be imported, what if the user changes it? Should OAuth pull this info on every login and change accordingly like when using Twitter/Facebook/Google logins with IPB? 

 

Thanks again. This is pretty cool so far. 

[wohali]

Thanks for the post on your nginx config - hopefully that will help someone else.

Rocket.Chat does not pull avatars in its OAuth configuration so that part of the integration won't work for Rocket.Chat. For their other integrations (GitHub, e.g.) the avatar import code is hardcoded as a workaround. I've filed a bug about this upstream.

Your other questions are really Rocket.Chat configuration changes - you'll need to file issues with them upstream similarly to lock down the behaviour as you wish. I am not aware of any way to currently achieve what you're trying to do.

 

[Ohio Riders]

21 hours ago, wohali said:

Thanks for the post on your nginx config - hopefully that will help someone else.

Rocket.Chat does not pull avatars in its OAuth configuration so that part of the integration won't work for Rocket.Chat. For their other integrations (GitHub, e.g.) the avatar import code is hardcoded as a workaround. I've filed a bug about this upstream.

Your other questions are really Rocket.Chat configuration changes - you'll need to file issues with them upstream similarly to lock down the behaviour as you wish. I am not aware of any way to currently achieve what you're trying to do.

 

Thanks for the info, and the plugin. 

[RevengeFNF]

@wohali I installed the new 4.1.14 RC and the oauth its not working anymore. It gives the following error when we click the the login button on rocket chat:

The link with sensitive information removed/changed is:

https://www.test.com/applications/oauth2server/interface/authorize.php?client_id=34j5kj34jhj34&redirect_uri=https://chat.test.com/_oauth/ips4&response_type=code&state=sjdfksdjhfkjsdf87s7df9sjdfgjhsgdf86s86dfjgsdgf8s6df86sdfhjgsjdhgf8s6df86sdfhgsjdhfg8s6df896sdfgjsdf896=&scope=openid

 

Maybe this changes are the reason?

 

[wohali]

Hi @RevengeFNF, thanks for the heads up. Indeed it's likely that the changes to the Url constructor are at fault. I'll have time to diagnose this later this week. Hopefully I can get a fix made before 4.1.14 is released, but given the new classes it will have to be a non-backwards-compatible release to the integration.

[wohali]

OK @RevengeFNF and others, I'm attaching a beta of Oauth 2 Server 1.1.0 to this message. This should solve your problems, and should be backward compatible with IPS 4.1.13 and lower. The issue was not, in fact, the Url class, but an undocumented change to the IPS Dispatcher class.

After installing this new version, only if you are running IPS 4.1.14 or newer, you are going to have to change the 3 URLs you use to integrate in your client application (such as Rocket.Chat). Previously the URL had the form:

https://sitename.com/applications/oauth2server/interface/authorize.php

Now they have this form:

https://sitename.com/applications/oauth2server/interface/oauth/authorize.php

The ACP page has been updated with this change.

If you can test this out and let me know it works for you, I'll upload this to the Marketplace.

oauth2server-1.1.0-beta.tar

[RevengeFNF]

@wohali when i click the login button, it opens the popup without the 404 error this time, but then it says in the rocket chat: "No matching login attempt found".

I think this is well configured:

[wohali]

Shoot. I can't reproduce this on my site, the integration works correctly now for me.

Can you try full uninstalling then reinstalling the OAuth integration from IPS, then install the beta for me and try again?

[RevengeFNF]

@wohali ok gonna try it.

Ps: Im using the last version of rocket.chat 

[RevengeFNF]

@wohali Still the same issue after uninstalling and reinstalling again.

The rocket.chat logs says:  invalid Scope

I think this is something new introduced in Rocket.chat 0.37 that forces the Scope to be the same in the ips and chat server. 

 

In the rocket.chat now i have the Scope variable, that is defaulted with "openid". I think we should be able to also define that in the oauth app in IPS.

The rocket.chat change was this one: https://github.com/RocketChat/Rocket.Chat/pull/3837

PS: I removed the Scope from the Rocket.Chat and its working now.

[wohali]

Excellent, glad to see there is a workaround for now.

I have a plan to support scopes in the plugin but it's going to take a little bit of time.

I will see if I can fix the scope support before releasing 1.1.0, but if it takes too long will get this fix out there so people are not blindsided by the 4.1.14 release.

[wohali]

v1.2.0 is uploading now. Here are the release notes:

• Fixes for IPS 4.1.14. Note that v1.2.0 is not backwards compatible with 4.1.13 and below. For older IPS releases, please continue to use v1.0.1.
• Scope support is complete and now recommended for Rocket.Chat integration.
  • Allowed scopes can be specified in the ACP on a per-application basis
  • Scopes can (and should!) be specified on initial authorization requests. If none is specified, all allowed scopes for the application are authorized.
  • The initial form that displays to users asking them to approve the authorization request lists which scopes are being requested by the OAuth Application (Client)
  • User primary and secondary group information is available by adding the user.groups scope to your initial authorization request.
• Rocket.Chat integration steps are documented in an included RocketChat-Readme.html file which is viewable on GitHub.
• Up-to-date documentation can always be found at GitHub.

[wohali]

v1.2.1 posted. New features:

• Language strings are now used for all text in the authorization form template displayed to first-time users of the OAuth integration.
• New scope support for user reputation points. Request user.reputation in the scope string for this data. (Thanks @Recouse!)

[wohali]

v1.2.3 posted to fix a regression with the token expiry task.

Note: If tasks refuse to run in your IPS instance, it may be necessary to run the following command against your IPS SQL database to fix the OAuth 2installation:

DELETE FROM enco_core_tasks WHERE `key` = 'expire_tokens';

The alternative would be to fully uninstall, then reinstall the OAuth2 Server application.

[wohali]

v1.2.4 released to fix a minor regression where the new URL path was not displaying correctly in the ACP details for an OAuth integration.

[RevengeFNF]

Rocket.Chat using a widget on my forum looks really nice.