You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As we push to move away from Personal Access Tokens (and the v1.1 API) we need to rewrite the authentication on this plugin to use OAuth.
One question that remains before we can task this: How do we store the OAuth Client Secret in a secure manner? If we use the same OAuth Application for all WordPress users it would require the same secret and anyone who acquired it could impersonate the app for nefarious purposes. If we don't use the same secret but require each user to create their own oauth app, it kind of defeats the purpose of oauth and breaks our own general application guidelines.
One possible option would be to build out some sort of expanded Oauth implementation that has a one public and many private keys. We could embed the public key in the API and require the user to enter their personal private key during registration. However, each user would need a different private key, and this approach also makes the Oauth part seem almost pointless since we'd be requiring a user provided string before we could even begin the auth flow.
Other ideas?
The text was updated successfully, but these errors were encountered:
Per site oauth app that we hide from normal visibility? 😭
Or maybe we get rid of ExternalSite as a table entirely and merge it a type of oauth app?
Although I also think it would be useful for accounts to be able to get their own webhooks too, without creating a separate app. Maybe that is also a hidden app? 😂
The downside of per-site app is the same as a private key. The user has to copy in values to get the Oauth to work rather than just "click to connect".
However, perhaps we could do some per-user "compiled" plugin distro? It loses the marketing we get from the public plugin repo (which... probably isn't much) and the automated upgrades (unless you can tell wp to look somewhere else for upgrades for one plugin).
Or, perhaps a combination of the two? A public plugin published and upgraded through the WP public repo, and a private plugin (or even just a file?) that the user downloads from Secure containing their personal keys to begin the auth flow.
As we push to move away from Personal Access Tokens (and the v1.1 API) we need to rewrite the authentication on this plugin to use OAuth.
One question that remains before we can task this: How do we store the OAuth Client Secret in a secure manner? If we use the same OAuth Application for all WordPress users it would require the same secret and anyone who acquired it could impersonate the app for nefarious purposes. If we don't use the same secret but require each user to create their own oauth app, it kind of defeats the purpose of oauth and breaks our own general application guidelines.
One possible option would be to build out some sort of expanded Oauth implementation that has a one public and many private keys. We could embed the public key in the API and require the user to enter their personal private key during registration. However, each user would need a different private key, and this approach also makes the Oauth part seem almost pointless since we'd be requiring a user provided string before we could even begin the auth flow.
Other ideas?
The text was updated successfully, but these errors were encountered: