[question] Headless API use case

[andrewmclagan]

The architecture of the auth flow in this plugin is great; I understand the security concerns. Although it disables perhaps the primary use-case of such a feature: Wordpress as a headless CMS.

Disables headless CMS authentication

A headless CMS would require users to login via username and password. Once the user has a JWT they can send authenticated requests to protected resources, in a headless CMS environment it would be prohibitive and counterintuitive to ask users to generate API tokens.

Security should be implemented through RBAC privileges, user roles and responsibilities dictating whats protected in the API. Security concerns could be mitigated via very strict defaults of RBAC. Already Wordpress has a great roles and responsibilities framework.

To address the actual security concerns:

• Long lived tokens? Make them short lived tokens.
• Concerns that long lived tokens can be stolen? So can API tokens, null argument.
• JWT best practices dictates short lived tokens and long lived refresh_tokens (refresh tokens are revokable) Thus this is more secure than handing out infinite lived API tokens that can be lost.

Isn't this just OAuth2 ?

This approach is essentially an oAuth2 "personal access" token grant scenario. Thus I would question the merits of a custom token auth server approach such as this over a proper oAuth2 standard implementation? If security is the primary concern here, then this approach actually presents security risks? e.g. a battle tested implementation of oAuth2 such as php-league-oatuh-2

I see the only viable use case for the current auth flow application-to-application authentication? oAuth2 lays out multiple auth flow methods to grant tokens. One being what this approach uses "personal access" and another being what I'm describing "password access" tokens. A full oAuth2 implementation would allow both of these scenarios and more...

Further

We believe the uptake of the WP-API and thus the modernisation of the Wordpress ecosystem in general would be greatly enhanced if things such as stateless API auth was easily accessible to developers.

These are just musings and would love to discuss and contribute!

Great work!

wp-headless team

[kosso]

I've been building native apps (or trying to) since before the REST API made it to core. (ie: years)

Initially, the only way for my app to authenticate and upload/create content was to use the 'OAuth1.0a' plugin which the API team started.

I now have things working for OAuth2.0 (again, another feature that needs an extra plugin installed. No idea if this is ever going to get to core)

And now we have JWT which presents new problems in how to get my app connected. Naturally a username/password would work better, providing a token. (Luckily this 'WP-API' version of JWT support token refreshing. Another widely-used JWT plugin doesn't)

I can't believe the sheer amount of lost opportunities (and time) which are going by, with not having a solid 'headless'/mobile implementation for authentication 'out of the box' (in core).

My mobile app requires its own plugin to do its job and support a load of admin related things and route enhancements. custom blocks etc. I'd rather not have to get my app users/customers to have to download and install another 'not-quite-finished' plugin.

I just wish a solid (and 'official') solution existed.

[andrewmclagan]

I strongly agree. Wordpress is positioned to become a leader in the headless cms arena. It seems the core team makes inroads to that, but maybe only to serve a specific use case for wordpress.com? Not sure.

We are currently developing an isomorphic client for this purpose. Along with react hooks and providers. https://github.com/wp-headless/fetch. Perhaps we are going to have to write our own JWT auth plugin. My thoughts on what it should looks like:

• Follow oAuth2 specs (why create a custom auth flow?)
• Have multiple token grant methods: password, machine-to-machine, api-key etc..
• depend on leading packages that are well tested.

[w33zy]

Here I am stuck with trying to implement a user registration/authentication system via the WP REST API, only to find out the WP team is reinventing the wheel inventing a new wheel.