WordPress.com Secure Sign On

Using the same log-in credentials you use for WordPress.com, you’ll now be able to register for and sign in to self-hosted WordPress.org sites quickly and securely.

Benefits

Millions of users: By adding WordPress.com Secure Sign On, you’ll become part of a large family that makes it easy for WordPress.com users to explore new sites thanks to the Reader.
Compatible with your existing sign-in system: WordPress.com Secure Sign On is used as a complementary sign-in option to your existing registration system. Once a user connects, they’ll have a user account on your site.
Respects your Registration Settings: WordPress.com Secure Sign On follow the directives in Settings → General, with respect to whether or not you enable new user registrations. If you don’t, existing users can still use it to log in.
Trusted relationship: Allow users to sign in with the same credentials they use every day on WordPress.com. This takes the pain out of having to remember and manage a new log-in for another service.

Enabling this Feature

To enable this feature, you can do so at any time by toggling the Allow users to log in to this site using WordPress.com accounts setting in the WordPress.com log-in section from Jetpack → Settings → Security in your dashboard.

Once you’ve activated this feature in Jetpack, you’re done! All the back-end authentication requests use your site’s already-established link to WordPress.com.

Matching Accounts by Email

If there isn’t already a local account linked to the WordPress.com account, Secure Sign On can automatically link the verified WordPress.com account to a pre-existing local account with a matching email address and log the user in.

By default, this feature is disabled, and users are required to log in to their pre-existing local accounts to manually link the accounts. When a user logs in with their WordPress.com account, if there is no pre-existing local account that has been connected to WordPress.com, the login will not go through. Here’s the error the user will see:

If you’d like to enable this functionality for automatic matching and linking with email addresses of pre-existing local accounts on the site, you can toggle the Match accounts using email addresses option to turn it on.

Requiring Two-Step Authentication

If you’d like to improve the security of Secure Sign On, you can choose to force Two-Step Authentication when users log in via WordPress.com. To do so, toggle the Require accounts to use WordPress.com Two-Step Authentication to turn it on.

Note: This setting only requires that logging in via WordPress.com requires Two-Step Authentication. If you turn it on without disabling the default login form, then a user could still log in via the default form. If you would like to enforce Two-Step Authentication for your site, you could combine turning this on with the jetpack_remove_login_form filter described below to force users to log in with WordPress.com and use an account with Two-Step Authentication.

Additional Custom Settings

Secure Sign On is designed to work out of the box with little to no configuration. But, for users that would like to further customize Secure Sign On, these filters may come in handy. To use these filters, you can add any of the following snippets of code to your theme’s functions.php file, or to a functionality plugin.

As a note, you can mix and match these filters to get the desired functionality that you need.

New User Override

The WordPress.com Secure Sign On feature will respect your default settings with regard to New User Registration. If you have registration disabled, then Secure Sign On will not create a new user account if someone is trying to log in with an unrecognized email. If you have registration turned on, though, it will automatically create a new user for them, and log them in. If you would like to allow users to register for your site with a WordPress.com account, even though you disallow normal registrations you can use the following line of code:

add_filter( 'jetpack_sso_new_user_override', '__return_true' );

Bypass Default Login Form

If you’d like all registered users to log in via WordPress.com instead of the account they created on your site, you can use the following line of code. It will forward all users to the WordPress.com SSO page, thus bypassing your local log in screen:

add_filter( 'jetpack_sso_bypass_login_forward_wpcom', '__return_true' );

Disable Default Login Form

If you’d like to completely disable and hide the default login form, and force users to log in via WordPress.com, you can use the following line of code:

add_filter( 'jetpack_remove_login_form', '__return_true' );

Please be aware that these snippets are provided as a courtesy and our support team is unable to offer assistance customizing them further.

Privacy Information

WordPress.com Secure Sign On is deactivated by default. You activate/deactivate it form your WP Admin. To do so:

Go to Jetpack → Settings.
Click the Security tab.
Toggle the Allow users to log in to this site using WordPress.com accounts setting in the WordPress.com login section.

More information about the data usage on your site

Data Used
Site Owners / Users This feature requires the usage of the following pieces of data relating to users logging in via this method: user ID (local and WordPress.com), role (e.g. administrator), email address, username and display name. The following pieces of data relating to the site are also used: WordPress.com-connected site ID, Jetpack active/inactive status, Jetpack version, locale/language, title, URL, and icon. Additionally, for activity tracking (detailed below): IP address, WordPress.com user ID, WordPress.com username, WordPress.com-connected site ID and URL, Jetpack version, user agent, visiting URL, referring URL, timestamp of event, browser language, country code.	Site Visitors None.
Activity Tracked
Site Owners / Users We track when, and by which user, the feature is activated and deactivated. Additionally, the following usage events are recorded: starting the login process, completing the login process, failing the login process, successfully being redirected after login, and failing to be redirected after login. Several functionality cookies are also set, and these are detailed explicitly in our Cookie documentation.	Site Visitors None.
Data Synced (Read More)
Site Owners / Users We sync options that identify whether or not the feature is activated and how its available settings are configured. We also sync the user ID and role of any user who successfully signed in via this feature.	Site Visitors None.

Data Used

Site Owners / Users

This feature requires the usage of the following pieces of data relating to users logging in via this method: user ID (local and WordPress.com), role (e.g. administrator), email address, username and display name. The following pieces of data relating to the site are also used: WordPress.com-connected site ID, Jetpack active/inactive status, Jetpack version, locale/language, title, URL, and icon.

Additionally, for activity tracking (detailed below): IP address, WordPress.com user ID, WordPress.com username, WordPress.com-connected site ID and URL, Jetpack version, user agent, visiting URL, referring URL, timestamp of event, browser language, country code.

Site Visitors

None.

Activity Tracked

Site Owners / Users

We track when, and by which user, the feature is activated and deactivated.

Additionally, the following usage events are recorded: starting the login process, completing the login process, failing the login process, successfully being redirected after login, and failing to be redirected after login.

Several functionality cookies are also set, and these are detailed explicitly in our Cookie documentation.

Site Visitors

None.

Data Synced (Read More)

Site Owners / Users

We sync options that identify whether or not the feature is activated and how its available settings are configured. We also sync the user ID and role of any user who successfully signed in via this feature.

Site Visitors

None.