Plugin / IndieAuth

IndieAuth is an extension to OAuth. If you are a developer, you have probably used OAuth to get access to APIs. As a user, if you have given an application access to your account on a service, you probably used OAuth. One advantage of IndieAuth is how easily it allows everyone’s website to be their own OAuth Server without needing applications to register with each site.

IndieAuth was built on top of OAuth 2.0 and differs in that users and clients are represented by URLs. Clients can verify the identity of a user and obtain an OAuth 2.0 Bearer token that can be used to access user resources. You can read the specification for implementation details.

The goals of OpenID and Web Sign In are similar. Both encourage you to sign in to a website using your own domain name. However, OpenID has failed to gain wide adoption. Web sign-in prompts a user to enter a URL to sign on. Upon submission, it tries to discover the URL’s authorization endpoint, and authenticate to that. If none is found, it falls back on other options. This plugin only supports searching an external site for an authorization endpoint, allowing you to log into one site with the credentials of another site. This functionality may be split off in future into its own plugin.

Indieauth.com is the reference implementation of the IndieAuth Protocol and available for public use. If you activate this plugin you do not need to use this site. IndieAuth.com uses rel-me links on your website to determine your identity for authentication, but this is not required to use this plugin.

As of version 3.2, the endpoints return the display name, avatar, and URL from your user profile.

No. When you provide the URL of the WordPress site and authenticate to WordPress, it will return the URL of your author profile as your unique URL. Only one user may use the URL of the site itself. This setting is set in the plugin settings page, or if there is only a single user, it will default to them.

That, as mentioned, depends on the server. By default, the built-in IndieAuth server uses the WordPress login. By adding Indieauth support, you can log into sites simply by providing your URL.

We recommend your site uses SSL to ensure your credentials are not sent in cleartext. As of Version 3.3, this plugin supports Proof Key for Code Exchange(PKCE), if the client supports it.

Once you have proven your identity, the token endpoint issues a token, which applications can use to authenticate as you to your site. The plugin supports you using an external token endpoint if you want, but by having it built into your WordPress site, it is under your control. You can manage and revoke tokens under User->Manage Tokens. You will only see tokens for the currently logged in user.

The WordPress function, get_current_user_id works to retrieve the current user ID if logged in via IndieAuth. The plugin offers the following functions to assist you in using IndieAuth for your service. We suggest you check on activation for the IndieAuth plugin by asking if ( class_exists( 'IndieAuth_Plugin') ) indieauth_get_scopes() – Retrieves an array of scopes for the auth request. indieauth_check_scope( $scope ) – Checks if the provided scope is in the current available scopes indieauth_get_response() – Returns the entire IndieAuth token response indieauth_get_client_id() – Returns the client ID indieauth_get_me() – Return the me property for the current session. new IndieAuth_Client_Discovery( $client_id ) – Class that allows you to discover information about a client $client->get_name() – Once the class is instantiated, retrieve the name $client->get_icon() – Once the class is instantiated, retrieve an icon If any of these return null, the value was not set, and IndieAuth is not being used. Scopes and user permissions are not enforced by the IndieAuth plugin and must be enforced by whatever is using them. The plugin does contain a list of permission descriptions to display when authorizing, but this is solely to aid the user in understanding what the scope is for. The scope description can be customized with the filter indieauth_scope_description( $description, $scope )

The plugin allows you to generate a token under User->Manage Tokens with access. You can provide this to an application manually.

Many server configurations will not pass bearer tokens. The plugin attempts to work with this as best possible, but there may be cases we have not encountered. The first step is to try running the diagnostic script linked to in the settings page. It will tell you whether tokens can be passed. Temporarily enable WP_DEBUG which will surface some errors in your logs. If you feel comfortable with command line entries, you can request a token under Users->Manage Tokens and use curl or similar to test logins. Replace example.com with your site and TOKEN with your bearer token. curl -i -H 'Authorization: Bearer TOKEN' 'https://example.com/wp-json/indieauth/1.0/test curl -i -H 'Authorization: Bearer test' 'https://tiny.n9n.us/wp-json/indieauth/1.0/test?access_token=TOKEN' This will quickly test your ability to authenticate to the server. Additional diagnostic tools may be available in future. If this does not work, you can add define( 'INDIEAUTH_TOKEN_ERROR', true ); to your wp-config.php file. The INDIEAUTH_TOKEN_ERROR flag will return an error if there is not a token passed allowing you to troubleshoot this issue, however it will require authentication for all REST API functions even those that do not require them, therefore this is off by default. If your Micropub client includes an Authorization HTTP request header but you still get an HTTP 401 response with body missing access token, your server may be stripping the Authorization header. If you’re on Apache, try adding this line to your .htaccess file: SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1 If that doesn’t work, try this line: RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] If that doesn’t work either, you may need to ask your hosting provider to whitelist the Authorization header for your account. If they refuse, you can pass it through Apache with an alternate name. The plugin searches for the header in REDIRECT_HTTP_AUTHORIZATION, as some FastCGI implementations store the header in this location.

Some hosting providers filter this out using mod_security. For one user, they needed Rule 340162 whitelisted as it detects the use of a URL as an argument.