API Bearer Auth vs Passwords Evolved

The API Bearer Auth plugin enables authentication for the REST API by using JWT access an refresh tokens. After the user logs in, the access and refresh tokens are returned and can be used for the next requests. Issued tokens can be revoked from within the users admin screen. See below for the endpoints. Note that after activating this plugin, all REST API endpoints will need to be authenticated, unless the endpoint is whitelisted in the api_bearer_auth_unauthenticated_urls filter (see FAQ for how to use this filter). JWT Access tokens can be formatted as JWT tokens. For this to work, you first have to create a secret and add it to the wp-config.php file. If you don’t do this, access tokens will work also, but are just random strings. To create a random secret key, you can do for example: base64_encode(openssl_random_pseudo_bytes(64)); And then add the result to wp-config: define('API_BEARER_JWT_SECRET', 'mysecretkey'); If you have problems, you can verify your JWT tokens at: https://jwt.io/ Revoke tokens This plugin adds a column to the users table in de admin where you can see when a token expires. You can also revoke tokens by selection the “Revoke API tokens” from the bulk actions select box. API endpoints Note that all endpoints expect JSON in the POST body. Login Endpoint: POST /api-bearer-auth/v1/login Request body: Note: client_name is optional. But if you use it, make sure to use it as well for the refresh call! {"username": "my_username", "password": "my_password", "client_name": "my_app"} Response: { "wp_user": { "data": { "ID": 1, "user_login": "your_user_login", // other default WordPress user fields } }, "access_token": "your_access_token", "expires_in": 86400, // number of seconds "refresh_token": "your_refresh_token" } Make sure to save the access and refresh token! Refresh access token Endpoint: POST /api-bearer-auth/v1/tokens/refresh Request body: Note: client_name is optional. But if you did use it for the login call, make sure to use it here as well! {"token": "your_refresh_token", "client_name": "my_app"} Response success: { "access_token": "your_new_access_token", "expires_in": 86400 } Response when sending a wrong refresh token is a 401: { "code": "api_api_bearer_auth_error_invalid_token", "message": "Invalid token.", "data": { "status": 401 } } Do a request After you have the access token, you can make requests to authenticated endpoints with an Authorization header like this: Authorization: Bearer Note that Apache sometimes strips out the Authorization header. If this is the case, make sure to add this to the .htaccess file: RewriteCond %{HTTP:Authorization} ^(.*) # Don't know why, but some need the line below instead of the RewriteRule line # SetEnvIf Authorization .+ HTTP_AUTHORIZATION=$0 RewriteRule ^(.*) - [E=HTTP_AUTHORIZATION:%1] If you are not logged in or you send an invalid access token, you get a 401 response: { "code": "api_bearer_auth_not_logged_in", "message": "You are not logged in.", "data": { "status": 401 } } Important update Update immediately if you’re using a version below 20200807. Before this version all access tokens were updated when calling the refresh callback. If you are affected by this the fastest solution is to execute this query: update wp_user_tokens set access_token_valid = NOW(); This will invalidate all access tokens. This means that all users need to refresh their access token and will get a new access token and a unique one this time. A big thank to @harchvertelol for reporting this and suggesting the fix as well!

Important Notice: This plugin is no longer supported on wordpress.org. Please open issues on GitHub. The goal of this plugin is to shore up the WordPress authentication using standard security practice recommendations. At this time, the plugin improves WordPress authentication by doing the following: Enforcing uncompromised passwords This plugin prevents someone from using passwords that have appeared in data breaches. Whenever someone logs into a WordPress site, it’ll verify their password using the Have I been pwned? API. If their password appeared in a data breach, the plugin will prevent them from logging in until they reset their password. By default, this level of enforcement is only done on an account that has the “administrator” role. You can change which roles have their passwords enforced from the settings page. For people that have a role where there’s no password enforcement, the plugin will show a warning when they log in with a compromised password. The enforcement of uncompromised password also extends to when someone resets or changes their password. That said, in those situations, using an uncompromised password is mandatory. Someone will never be able to reset or change their password to one that’s appeared in a security breach. (As long as the plugin is able to contact the API.) Using stronger password hashing The plugin also encrypts passwords using either the bcrypt and Argon2 hashing functions. These are the strongest hashing functions available in PHP. Argon2 is available natively starting with PHP 7.2, but the plugin can also encrypt passwords on older PHP versions using the libsodium compatibility layer introduced in WordPress 5.2. You don’t have to do anything to convert your password hash to a stronger encryption standard. The plugin will take care of converting it the next time that you log in after installing the plugin. If you decide to remove the plugin, your password will continue working and remain encrypted until you reset it. It’s also worth noting that using a stronger hashing function is only important in the advent of a data breach. A stronger password hashing function makes decrypting the passwords from the data breach a lot harder to do. This combined with the enforcement of uncompromised passwords will help ensure that those passwords are never decrypted. (Or at least without significant effort.)