[RFC] Auth Plugin Refactoring & User Integration

[Hardolaf]

Previous 3.1 Discussions
GSoC Project

End Goal: An object-oriented interface for authentication backends allowing multiple authentication plugins to be selected simultaneously and allows them to change the user interface. Profile changes to both account settings and profile data should either be preventable by such plugins or cause notification of the respective plugin so the data can also be changed in its own database. Refactoring existing function-based authentication plugins and adding an OpenID implementation.

Proposed Changes

1. Authentication (login)
   1. Create method to handle login from a 3rd party service.
   2. Allow login via forum username/password or 3rd party authentication.
2. Registration
   1. Allow the use of the same username as a 3rd party service or one specific to forums.
   2. Require the user to have a separate forum password in case they de-authorize all 3rd party services.
   3. Copy over contact information from the 3rd party service including e-mail if possible into the registration forum, let user change any information before concluding registration. (Optional)
   4. Authorize the 3rd party service by default.
3. User Control Panel
   1. Authorize 3rd party authentication.
      1. Allow the user to authorize a 3rd party service to let them log into their account.
      2. Allow the user to copy information from 3rd party at this stage (ask user about each element?) (Optional)
   2. De-authorize 3rd party authentication.
      1. Allow a user to remove an authorized 3rd party service.
4. Admin Control Panel
   1. 3rd Party Services
      1. Choose which services to allow.
      2. Completely clear authorization of a particular service.
   2. User Admin
      1. Allow admin to deauthorize a user from using a specific service on the phpBB forum.
      2. Allow admin to ban a user from a specific service. (Optional)
      3. Allow admin to ban a specific user on a 3rd party service from registering on the site.
5. Authorization Request
   1. Redirect page
      1. Redirects the user to 3rd party service for authorization.
      2. Ask the service for the authorization key.
   2. Login Request
      1. Ask the 3rd party service for authentication on login using the authorization key.
      2. If authorization is no longer granted, asks the user to reauthorize the account via the redirect page.
   3. Deauthorization Request
      1. Send information to the service (possibly a redirect page to them) that would deauthorize the phpBB site to login a specific user.
   4. The Request
      1. May need to be specific for each service depending on how they want data formatted.
      2. Formatting of the request could be done using a switch for each service (not sure how well this would integrate with plugins).
6. Database changes
   1. Authorizations
   2. Authorization bans

Third Party Auth Services to Use:

• OpenID
• Google
• Facebook

Mockups:

User Control Panel for Third Party Login Services


Authorize an account to login. "Authorize" button would send the user to the appropriate third party website where they can allow authorization (javascript to bring up popup window to do this?).


Login with either your phpBB credentials or your registered OpenID credentials.


Registration page. Would go after the "You must be 13 or older to register"/terms of service page and before the actual account creation page. It would send the user to the third party site to authorize the account, then send the user back to set a phpBB password and set their account information.

Ticket: http://tracker.phpbb.com/browse/PHPBB3-9734
Pull Request (WIP): https://github.com/phpbb/phpbb3/pull/836

Edit 1: Add list of Third Party Auth Services
Edit 2: Add mock-up diagrams.

[naderman]

Do you have any plans for how this would work for Admin Reauthentication where you currently need to retype your password?

[Oleg]

Maybe a paranoid option where external auth for admins would never be accepted?

Edit: I suppose this won't be usable for stuff like intranet auth against ldap, hmm.

[naderman]

No indeed. I can see us requiring a password for that step and distinguishing between passworded and password-free systems in some sense? As long as you can add a password to your facebook authenticated login to have facebook+db auth work with your account, you could then use the password to reauthenticate.

[Hardolaf]

I was thinking of requiring a password for all users in case they lose access to their third party login service. This password could be used for admin reauthentication.

[ecwpa]

I think that's necessary. phpBB can't store user's third party password so in order to create an account you need a phpBB password. Login to admin area should require user's phpBB password too.

Now, about user registration. What happens if phpBB requieres email verification? Are people coming from a third party bypassing this?

[naderman]

I was thinking of requiring a password for all users in case they lose access to their third party login service. This password could be used for admin reauthentication.

Hm, doesn't that make using something like facebook login less convenient though? On the other hand I guess you need to select a username anyway, so we can just display a password field there.

[naderman]

Now, about user registration. What happens if phpBB requieres email verification? Are people coming from a third party bypassing this?

I guess that would have to be an option depending on the backend? You probably trust Google to provide you with a working email address, so there's no need to make users jump through the extra hoop of activation. At the same time there might be another auth plugin, where you'd rather verify emails anyway. Not sure if this should be hardcoded into the plugins or whether the admin should be able to pick this for each authentication method.

[ecwpa]

You probably trust Google to provide you with a working email address

I do not. Lots of bots managed to bypass user activation with Gmail addresses. Hard to believe but it happened to me.

[Hardolaf]

I guess that would have to be an option depending on the backend? You probably trust Google to provide you with a working email address, so there's no need to make users jump through the extra hoop of activation. At the same time there might be another auth plugin, where you'd rather verify emails anyway. Not sure if this should be hardcoded into the plugins or whether the admin should be able to pick this for each authentication method.

I support adding this an option. For some forums this may not be needed, but for others it may be necessary.