QRAuth – Passwordless & Social Login vs WP Cassify

QRAuth replaces the password field on your WordPress login page with a drop-in QR widget. Users sign in by scanning with the QRAuth mobile app; a cryptographic signature is verified server-to-server before WordPress sets the auth cookie. Social login (Google, GitHub, Microsoft, Apple) is brokered by QRAuth’s hosted approval page, so you never have to register an OAuth app or hold a client secret. One Client ID is the only configuration. Paste it into Settings → QRAuth and the widget appears on wp-login.php. Everything else — the approval flow, the signing, the token refresh — lives in the QRAuth platform. Account safety is the default. Auto-provisioning is off out of the box: only WordPress users who already exist (matched on email) can sign in via QRAuth. Flip on auto-provisioning and new users are created as Subscriber — that’s the only role available, intentionally and at every layer (settings UI, sanitiser, runtime). Operators who need a different role for an individual user can change it manually via Users → All Users after their first sign-in. The plugin never stores the signing material, never issues a redirect outside your site, and never touches your user table on uninstall. Self-hosted, no third-party scripts on wp-login.php. The QRAuth web component ships vendored inside the plugin — the only outbound call is from your server to QRAuth’s verification endpoint during a sign-in attempt. Open source build. The compressed JavaScript at assets/js/qrauth-components.js is built from publicly available TypeScript source at https://github.com/qrauth-io/qrauth/tree/main/packages/web-components. The unminified source files are also vendored alongside the minified bundle inside this plugin (assets/js/source/) for offline review. See the Source section below for build instructions. External services This plugin connects to QRAuth (https://qrauth.io) — the identity verification service that performs the actual passwordless / social sign-in. QRAuth is operated by ProgressNet, the publisher of this plugin. Without QRAuth there is no widget and no sign-in. What the service is and what it is used for QRAuth verifies that the user who scanned the QR code (or completed a social-provider flow on the hosted approval page) is the same person who initiated the sign-in on your WordPress site, then returns a signed assertion that the plugin uses to set the WordPress auth cookie. What data is sent and when Auth-session creation — when a visitor opens a page that hosts the widget (wp-login.php, the registration form, a shortcode-enabled page, or a WooCommerce sign-in form), the plugin’s same-origin REST proxy sends your Client ID, Client Secret (server-side only — never exposed to the browser), and the host page URL to https://qrauth.io/api/v1/auth-sessions. No visitor data is included in this request. Sign-in verification — when the visitor approves the sign-in (by scanning with the QRAuth mobile app or completing a social-provider flow on QRAuth’s hosted approval page), the plugin’s REST proxy fetches the verified result from https://qrauth.io/api/v1/auth-sessions/verify-result. The response carries the QRAuth user identifier and, when the email scope is allowed in Settings → QRAuth, the user’s email address. The plugin uses this only to locate or create the matching WordPress user; nothing beyond a hashed link reference is retained. Hosted approval page — when a visitor on a phone taps “Continue with QRAuth”, the browser navigates to https://qrauth.io/a/ to complete the social-provider flow. This is a standard cross-domain navigation initiated by the visitor. The vendored web component (assets/js/qrauth-components.js) is served from your own WordPress site — there is no third-party JavaScript on wp-login.php, and the component does not contact qrauth.io directly from the browser; all server-to-server calls are proxied via your site’s REST API. Service terms and policies Terms of Service: https://qrauth.io/terms Privacy Policy: https://qrauth.io/privacy Data Processing Addendum: https://qrauth.io/dpa List of Sub-processors: https://qrauth.io/subprocessors Source The compiled bundle at assets/js/qrauth-components.js carries the following banner header at the top of the file: ` /*! * @qrauth/web-components v0.4.1 * Vendored by qrauth-passwordless-social-login. Do not edit by hand. * * Source: https://github.com/qrauth-io/qrauth/tree/main/packages/web-components * License: MIT * npm: https://www.npmjs.com/package/@qrauth/web-components * Build: npm install && npm run build:assets (see bin/fetch-web-components.mjs) * * The unminified TypeScript source for this bundle is also vendored at * assets/js/source/ — see assets/js/source/README.md for provenance. */ ` The unminified TypeScript source files are also vendored alongside the compiled bundle inside this plugin (assets/js/source/) for offline review. The plugin’s own source — PHP, the small browser adapter (assets/js/qrauth-adapter.js), build scripts, tests, and CI — is publicly maintained under GPL-2.0-or-later at: Plugin source repository: https://github.com/qrauth-io/qrauth-passwordless-social-login The PHP and assets/js/qrauth-adapter.js shipped in the plugin ZIP are non-minified — read them directly without checking out the repo. The vendored file assets/js/qrauth-components.js is a pinned production build of the public @qrauth/web-components library. The non-compiled source for that library is openly available: Source repository: https://github.com/qrauth-io/qrauth/tree/main/packages/web-components (MIT-licensed) npm release: https://www.npmjs.com/package/@qrauth/web-components — pinned to v0.4.1, sha512 in package.json under the qrauth.webComponentsIntegrity key Build instructions for the upstream library: https://github.com/qrauth-io/qrauth/blob/main/BUILDING.md To regenerate the vendored bundle from the pinned npm release, clone the plugin source repository linked above and run from its root: npm install npm run build:assets The build script bin/fetch-web-components.mjs (kept in the plugin source repository, not in the WordPress.org plugin ZIP) downloads the npm tarball, verifies its sha512 SRI hash against package.json#qrauth.webComponentsIntegrity, extracts the IIFE build, and writes it to assets/js/qrauth-components.js. CI runs the same script before the WordPress.org plugin-check job, so the bundle distributed on the directory always matches the published npm release. To rebuild from upstream source instead of the pinned tarball, follow BUILDING.md in the upstream library repository above.

If you’re happy with this plugin : As a reward for my efforts, I would like to receive T-shirts (or other goodies) as gifts from the universities or companies that use it. My size is L. Best regards. This Apereo CAS authentication plugin has no phpCas library dependency. This is not only an authentication plugin. You can build custom authorization rules according to cas user attributes populated. If user don’t exist in WordPress database, it can be created automatically. There are many features. You can customize everything. Website https://wpcassify.wordpress.com/ Development and release environment This plugin is now developed and tested from a github repository. You can find it here : https://github.com/WP-Cassify/wp-cassify-develop Don’t hesitate to contribute to this project. You can fork it and make pull requests ! Requirements Require at least PHP version 7.0 Require at least PHP CURL package Features included SLO (Single Log Out) support (thanks to dedotombo and me) Adding NCONTAINS operator (thanks to blandman) Fix bug on Gateway mode (autologin) (thanks to dedotombo again). Now it’s now necessary to hack theme files to fire it. Adding option logout on authentication failure to not disturb users Initialize PHP session at a later stage (on wp_loaded not on init) Adding some customs hooks and filters. Tested with Apereo CAS Server version 7.3.5 Compatible with CAS Protocol version 2 and 3 Automatic user creation if not exist in WordPress database. Synchronize WordPress User metas with CAS User attributes. Add support for multivaluate cas user fields. Now multivaluate fields can be serialized to be stored in custom WP User meta. Backup / Restore plugin configuration options settings You can choose CAS User attributes you want to populate. Then you can access them via PHP Session. Be careful, to access to CAS User Attributes from your theme file (from 1.8.4), use code below : wp_cassify_get_cas_user_datas() ); } ?> Set up WordPress Roles to User according to CAS User attributes. If plugin is network activated, you can define User Role Rule scope by blog id. Authorization rule editor. Compatible with WordPress Access Control Plugin. Manage URL White List to bypass CAS Authentication on certain pages. Much simpler bypass authentication with post method provided by Susan Boland (See online documentation). Create wordpress authentication form with redirect attribute like this (works only if URL bypass is enabled in settings) : true, 'remember' => true, 'redirect' => site_url( '/?wp_cassify_bypass=bypass' ), 'form_id' => 'loginform', 'id_username' => 'user_login', 'id_password' => 'user_pass', 'id_remember' => 'rememberme', 'id_submit' => 'wp-submit', 'label_username' => __( 'Username' ), 'label_password' => __( 'Password' ), 'label_remember' => __( 'Remember Me' ), 'label_log_in' => __( 'Log In' ), 'value_username' => '', 'value_remember' => false ); wp_login_form( $args ); ?> Receive email notifications when trigger is fired (after user account creation, after user login/logout). Define notifications rules based on user attributes values. Purge user roles before applying user role rules. Define user account expiration rules bases on CAS User attributes. Network activation allowed You can set Service Logout URL (Needs to have CAS Server with followServiceRedirects option configured). Add support for web application hosted behind a reverse proxy. (Thanks to franck86) Add custom hooks : wp_cassify_after_cas_authentication, wp_cassify_before_auth_user_wordpress, wp_cassify_before_redirect, wp_cassify_after_redirect. (See online documentation) Custom filter to perform custom cas server response parsing. Hook name : wp_cassify_custom_parsing_cas_xml_response (See online documentation) Custom shortcode to generate CAS login/logout link into your blog. (See online documentation) Debug settings, dump last xml cas server response. Detect if user has already authenticated by CAS from your public pages and perform auto-login with gateway mode Add ‘-IN’ and ‘-NOTIN’ operators to process array attributes values returned from CAS. When you have : $cas_user_datas['title'] = array( 'Student', 'Professor' ); Then you can use : (CAS{title} -IN "professor")