- PKCE Support is now present in Indieauth for WordPress. PKCE protects against intercepted authorization codes by ensuring a token endpoint can confirm that the client attempting to redeem an authorization code is the same client that requested it.
- Token generation is now done using SHA256, as opposed to the built-in WordPress Hashing.
WordPress hashing combines key stretching with eight passes of MD5. MD5 by itself is not very secure, but the WordPress hashing is much more so. The reason why a hash that isn’t more secure isn’t in WordPress Core itself is the fact that the features require newer versions of PHP than WordPress’s minimum version.
The change to using SHA256 bumps the minimum PHP version of the plugin to PHP5.4. That said, WordPress itself has scheduled finally upping its minimum to PHP 5.6 in WordPress Version 5.2 scheduled to be released next month, and will be looking to leverage anything useful in those versions. That may also cause WordPress itself to change its hashing to something less controversial.
The 3.0 branch of IndieAuth has added a lot of useful features.
The last release added profile support for returns, which allows a client to get the name and avatar of the user associated with the token, for display. The WordPress plugin was the first IndieAuth endpoint to adopt this experimental option, which is still under development, and Quill had to be updated to support it as a reference implementation.
IndieAuth is a fairly stable plugin, but there are still opportunities in future for expansion. A few things I’d like to do in future.
-
- Invalidate Tokens when a User Changes their Password
- Bulk Actions to Expire Tokens
- Implement Scope Support – Right now this is handled by whatever is being accessed, not the Indieauth plugin itself. This would be possible by mapping scopes to WordPress user capabilities.
Curious what others might want to see.
Reads
Likes