Add Indieauth as built in auth

[discobot]

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.

OAuth for the Open Web

---

Read-only archive: https://petitions.classicpress.net/posts/86/add-indieauth-as-built-in-auth

Author: David Shanske

Vote count: 7

Status: open

---

Comments

IndieAuth – WordPress plugin | WordPress.org

~ posted by David Shanske

I think that is not the case to integrate an external service in the core because the project is open source and we will bind to that.
At this point is better implement one time password as 2FA that will not bind to a service or a client software like Facebook, Github, and Firefox do.
This plugin 2FAS Prime — Two Factor Authentication – WordPress plugin | WordPress.org support that as example.

~ posted by Daniele Scasciafratte

Daniele, I think you are misunderstanding this. IndieAuth is an Oauth2 identity layer that I am proposing would be built into Core and would not depend on an external service. The Indieauth plugin I linked to, which I am a contributor to, implements an authorization and a token endpoint using the REST API, so inside the site itself. The only login you’d use to allow an applicaton to get a token is your WordPress login.

WordPress proposed using a more traditional Oauth2 implementation that requires client registration, and the team there had the idea of running that through a wordpress.org service. The IndieAuth variant could run exclusively inside a WordPress install(the plugin does this already).

~ posted by David Shanske

Thanks for the clarification, I was thinking that was a service for Oauth2 like many others

~ posted by Daniele Scasciafratte

I think developers want a way for their applications to get authenticated access to the REST API. That seems to be a constant demand. But few want the overhead or responsibility for third-party servers. This would bake all of that in.

~ posted by David Shanske

I think this is definitely worth exploring.

~ posted by James Nylen

Hey Daniele! I should have figured I’d find you here. I hope all is well!

Indieauth is an awesome OAuth2 solution using REST API.

If our goal. Is a stable system using open APIs it makes sense.

~ posted by Greg McVerry

[viktor]

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.

[alvarofranz]

Definitely plugin territory.

[joyously]

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.

[viktor]

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?

[joyously]

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.

[alvarofranz]

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.

[timkaye]

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.

[viktor]

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.

[timkaye]

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.

[joyously]

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…

[timkaye]

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

[viktor]

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?

[alvarofranz]

Yes …