Project

General

Profile

Actions

Feature #9720

open

The Commons should be an oAuth provider

Added by Boone Gorges almost 6 years ago. Updated about 5 years ago.

Status:
New
Priority name:
Normal
Assignee:
-
Category name:
Authentication
Target version:
Start date:
2018-05-07
Due date:
% Done:

0%

Estimated time:
Deployment actions:

Description

Let's use this ticket to track the project of making the Commons into an oAuth provider. This will allow third-party applications to offer account creation and authentication through the Commons.

The initial client will be the CUNY installation of Manifold, but we should build with an eye toward more general adoption.


Files

Screenshot_2018-05-07_20-58-21.png (59 KB) Screenshot_2018-05-07_20-58-21.png login Boone Gorges, 2018-05-07 10:11 PM
Screenshot_2018-05-07_21-04-45.png (71.9 KB) Screenshot_2018-05-07_21-04-45.png authorization Boone Gorges, 2018-05-07 10:12 PM
Screenshot_2018-05-07_21-05-44.png (39.5 KB) Screenshot_2018-05-07_21-05-44.png applications Boone Gorges, 2018-05-07 10:14 PM
Screenshot_2018-05-07_21-06-02.png (34.1 KB) Screenshot_2018-05-07_21-06-02.png revoke Boone Gorges, 2018-05-07 10:15 PM
Actions #1

Updated by Boone Gorges almost 6 years ago

A summary of progress to date.

For the moment, I"m using the WP OAuth Server plugin to act as a provider. https://wordpress.org/plugins/oauth2-provider It's imperfect, but it is probably workable. I've got a request in with the plugin authors to see if they'll be willing to accept some PRs or patches so that it'll be possible to use without monkey patches.

One of the important mods (I'm putting this here mainly for my own reference) is that the plugin automatically sets the WP current user based on the oAuth access_token. This makes sense in theory, but in practice it is wonky: it means that the client can perform any action that the WP user can perform - creating new posts, updating profile data, etc - regardless of the client 'scope'. The plugin is written in a lousy way that makes it hard to unhook this behavior. One of the main things I'll be asking them for is a simple toggle. We will then write our own endpoints with proper cap checks, or override the relevant parts of WP's permission_check() methods.

The basic flow works like this:
1. You go to a client site (this would eventually be cuny.manifoldapp.org and others) and click the "Log in with the CUNY Academic Commons" button or whatever. authorizationUrl is https://commons.gc.cuny.edu/?oauth=authorize&response_type=code&client_id=[client_id]&client_secret=[client_secret]&redirect_uri=[redirect_uri]
2. A window pops up. For consistency, I've designed it so that it has the same dimensions as the Google oAuth window currently used by Manifold.
3. If you're not logged into the Commons, you'll see the login form. See 'login' screenshot.
4. Once logged in, if you have not yet authorized this client application, you'll be asked to do so. See 'authorization' screenshot. The "scopes" here - email address, etc - are half working, in the sense that the messages you see here are generated based on the scopes that are assigned to the client, but they are not actually attached to the oAuth requests themselves. See the comment above.
5. The client will then be responsible for closing the window, redirecting, etc.

On the Commons side, users can see a list of authorized applications at Settings > Applications. See 'applications' screenshot. Access to them can be revoked on a case-by-case basis. See 'revoke' screenshot.

A technical note that WP oAuth Server stores clients as a WP post type. The client URL and client logo are not natively stored by the plugin. I just added them manually as postmeta. This is fine for the time being, but is another thing I'll need to work with their people to address.

Next steps:
1. Any feedback on this flow would be welcome.
2. I'll continue to work with WP oAuth Server folks to get the necessary improvements.
3. I'll write REST API endpoints that allow applications to fetch items in a way that's sensitive to the scopes of the clients. I think that for the time being this'll be a 'profile' endpoint that gives back email and/or profile data based on the 'email' and 'profile' scope assigned to the client whose key is in use.

Once 3 is done, I'll try to wrap everything up into a set of instructions that can be passed along to the Manifold team.

Actions #2

Updated by Matt Gold almost 6 years ago

Thanks, Boone! I think this looks great overall. I guess that one question I have is whether we need to show as much info in the step 2 pop-up window as we are now, like the main nav bar and the footer, which add a bit of clutter to that small window -- though if customizing what shoes up in the window is troublesome, it could definitely work as is.

Otherwise, this is all great. Many thanks for your work on it.

Actions #3

Updated by Boone Gorges over 5 years ago

  • Category name set to Authentication
Actions #4

Updated by Boone Gorges over 5 years ago

  • Target version changed from 1.14 to 1.15
Actions #5

Updated by Boone Gorges about 5 years ago

  • Target version changed from 1.15 to Future release

Tabling this feature, pending additional steps from Cast Iron.

Actions

Also available in: Atom PDF