API Bearer Auth vs GuardianKey

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!

GuardianKey is a service to protect systems in real-time against authentication attacks. It implements GK Auth Security for login protection and GKTinc dissuasion challenges, helping detect and block malicious accesses, and notify the legitimate user and the system administrator. Beyond the security, the GuardianKey solution provides a good user experience, because the user is not required to provide extra information or to execute tasks during the login. When GKTinc is enabled, the challenge runs automatically during login, with server-side validation in the plugin. GuardianKey’s approach provides a risk assessment in real-time. The events and risks can be explored in the GuardianKey’s administration panel. How GuardianKey works The GuardianKey detection engine analyzes the events sent by your online system to the GuardianKey servers. The detection engine uses Machine Learning and our secret mathematical risk formula to combine the following three analysis approaches: Threat Intelligence, Behavioral Profiling, and Psychometric Profiling. Using these three pillars, our engine computes a risk for each event sent by the protected systems. In real time, the online attempt can be blocked, an extra requirement can be requested to the user, or notifications can be triggered. All data sent to GuardianKey servers are doubly encrypted, and NOT send passwords or sensitive data. More information at https://guardiankey.io/ Plugin Installation Install GuardianKey from WordPress plugin directory, and activate plugin Go to https://panel.guardiankey.io/auth/register, and create account in GuardianKey Access GuardianKey panel (https://panel.guardiankey.io/) and go to Settings->Authgroups->edit/view/Deploy information and get keys Access Administration->Tools->GuardianKey in your WP and put keys of GuardianKey Configure GKTinc by filling API Key, Protection Group Hash ID, and Default Challenge Level If you want notify users, change “Notify Users” option to “yes” Using GuardianKey Access https://panel.guardiankey.io and login using the credentials sent to your e-mail address during the registration. You can recover the pass if you forgot it. GKTinc is optional and can be enabled in the plugin settings. When enabled, the plugin loads the GKTinc JS setup, injects the config generated by the SDK, and validates each login server-side. There is a documentation for the panel available at https://guardiankey.io/docs