Add Indieauth as built in auth

Indieauth is a layer on top of Oauth2. It eliminates the need for client registration by making your client id your URL. This solves the issue WordPress had with this.

Read-only archive:

Author: David Shanske

Vote count: 7

Status: open


This sounds like something that should be left to the plugins to implement. Anyone has experience with it? I don’t want to close it prematurely.

Definitely plugin territory.

To make something this useful available to all plugins, it should be in core, because having plugin dependencies is a complicated mess.

Since there is already a plugin, the key point is in the plugin’s FAQ:

How do I incorporate this into my plugin?

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.

If I understand correctly, you think this should be considered for core? Do you know if WP is looking at it in any way for core implementation?

This type of thing belongs in core, where it can be used by all. As stated:

I think developers want a way for their applications to get authenticated access to the REST API.

I know that’s why I’ve never messed with REST. The API is only half-useful if you don’t have a way to authenticate. Having a plugin solves one author’s problem only.
I don’t know what WP is looking at related to this.

The same happens with fields. Many people need them but there are many choices available, with different scopes and for different tastes.

I usually use JWT for auth and it works fine. Others may use something else. Making this into core is forcing a standard… maybe that’s why WP didn’t do it.

Also, it’s the kind of stuff that gets outdated when a new toy appears, and then we have a bloated core. Not even the whole REST API should have been merged into core. Some prefer graphQL which is slowly replacing REST, as REST replaced SOAP.

Let’s clean the Core, not fill it up with more future garbage.

In another petition I proposed to add a few lines of code to core to handle a JSON db with local files for specific and simple things. It’s also useful, but… “plugin dependency” was proposed.

So, the same for this shall apply.

GraphQL isn’t really replacing REST (and certainly not in WP). It’s just got a few noisy advocates. What actually tends to happen in most instances is that Graph gets added to a site that already has REST … which is actually a great example of your wider point.

I authenticate for REST using my own system, which actually requires multiple (non-human) users as well as tokens, and I don’t really see any advantage in switching to Indieauth. I also don’t understand why Indieauth uses URLs instead of email addresses.

So I vote to close this too.

How do application passwords fit into this? I remember there was some minor discussions about backporting them, but there was some pushback too. But I don’t remember details.

I use application passwords for what I do. Each non-human user gets an application password but no regular password.

Application passwords seem to me to be something worth having in core.

I wasn’t advocating that it be added to core (I didn’t vote for it). I was simply stating that it is the type of thing that is better when centralized instead of in a plugin because then you have plugin dependencies.
I think the REST API is only partially useful and yet it is there in core, duplicating a bunch of functionality…

Agreed about the REST API, which is why it should become a core plugin.

Since the plan is to move API into a core plugin, should we close this petition as it would mean authentication would also need to be in a plugin?

1 Like

Yes …

1 Like

This topic was automatically closed after 3 days. New replies are no longer allowed.