I am installing a CMS login that is shared between two organizations, one a blog for community designed for ease of login and the other is a staff PHP application for a related nonprofit, to keep track of membership and so forth using CiviCRM and a custom DB for business record keeping.
The composition of the staff logins is a variable subset of the users who are known CMS users, who have recognized logins. The composition of the blog users 100% of the CMS users. (Like Stack Exchange users vs. Stack Exchange users with account access on Server Fault). Moreover, the blog is geared to a diverse group of users, some of whom aren't on Facebook etc. and others are only on Facebook etc. so anything that's not a shared login would serve as a barrier.
To prevent hijacked foreign accounts from automatically gaining staff access, known users would receive staff privileges on the business app side through a user-privileges whitelist of known users with > 1 privileges (0 = non-logged in guest) coupled with an OAuth secondary login (staff ID) within the client app OpenID module. The OAuth secondary login would be an in-app lookup per-user once the OpenID identity has been established. The idea is that most users would already be logged into the main site (blog) and hence recognized.
Our current dev / tech support is familiar with HybridAuth and recommends it highly as a plug-in for custom PHP modules to interface with existing CMS login accounts and also with Facebook etc. using OAuth. HybridAuth also has provision for OpenID, but he is only familiar with using it for OAuth.
Based on my reading I would prefer to use OpenID since that would make the PHP app reusable not dependent on a single-client Drupal instance for logins.
App instance could still be married to a non-instance-specific Drupal library for CMS setup.
However, my preference is based on the following assumptions:
That HybridAuth is capable of implementing a secure, user-friendly version of OpenID. Since HybridAuth apparently has a good OAuth library, and supports OpenID, is it a good substitute for OpenID Connect as well? Does it have similar OpenID functionality?
That OpenID/Connect can now be configured in a user-friendly way to allow email id on a per-issuer basis? (I would confine it to issuers like Google and Facebook that allow email, or email password combos, to uniquely id users, and set up the local login accordingly.)
That OpenID/Connect can now be configured in a user-friendly way to allow offsite login via issuer (e.g. "sign in with Google or Facebook") in-frame or without having to go through multiple pages, preferably without having to leave the main site.
That Drupal or similar client-hosted CMS can be used as an OpenID issuer for local logins directly or on a sister site, like Stack Exchange does (I assume). I don't know how standard Drupal logins work. Is it like a universal Drupal ID, or is it site-specific and just a db layer? Does Drupal only support OpenID client login, not OpenID issuer? Is the Drupal issuer site-specific, if it exists, and is the Drupal issuer url-based?
That HybridAuth and/or OpenID Connect allows connect via existing OpenID (or one-click connect if already logged in to issuer) and then OAuth to services (staff user only).
That HybridAuth and/or Drupal has built-in OpenID Issuer module for the parent site that doesn't require a PhD. in PHP to install.
Is one or more of these assumptions incorrect? or does it not matter and I should use OAuth only? (I assume OAuth requires registering every app instance with the client CMS and the chosen social media providers; keep in mind that the app is on a different but related domain than the blog itself.)