Hello @ryanboder,
Thank you for reaching out to us today!
The article is ready and will be published very soon on our website, and I’ll let you know as soon as it’s available so you can take a look. I really appreciate your patience and understanding — talk to you soon!
Many thanks,
Hello again @ryanboder !
We have just published the article that highlights all you need to know in regards to this new plugin feature. It can be accessed here https://melapress.com/support/kb/wp-2fa-rest-api/
Thank you!
Thanks! I’m not sure I understand how to use it though. We’re building a headless WP/WC site and trying to figure out how to do 2FA at login. We’re assuming logging in from the frontend site will use a JWT plugin such as this or this.
I see that we can use your new endpoint to check whether a 2FA token is valid but if we do the 2FA test in the browser then it could easily be subverted. We would need the 2FA test to happen in the server and the JWT plugin to not provide an access token unless a valid 2FA token has been sent along with the username and password.
How could we incorporate WP 2FA into the login using this new endpoint?
Thank you for sharing the details of how you plan to use this @ryanboder
I’m just checking this with the team, to get some feedback, and I’ll share more info with you within a few days. Thank you for your patience.
Hello again @ryanboder and thank you for your patience!
Even though it’s still a bit unclear what/how you are trying to achieve, I will try my best to offer some clarifications. What you describe – tying JWT authentication together with a 2FA step during login in a headless setup – is exactly the type of scenario our REST API endpoints are meant to support. The endpoints allow you to verify a 2FA code and build that step into your own custom authentication flow.
That said, the exact way you chain this with a JWT plugin or how you enforce token issuance only after 2FA validation is something that depends heavily on your chosen stack and implementation. Since there are many different JWT plugins and “headless” site configurations, we’re not able to provide step-by-step development guidance for each scenario.
We’ll continue to expand and improve our documentation (the article I shared earlier will be updated as we go), but for now your development team will need to handle the integration details on your end.
If you find anything useful along this process which you think worth be shared with us and for anybody that may be checking this ticket, feel free to do so.
I hope the above helps, and if you have questions or any other additional info feel free to reach out!
I’m not asking for stack-specific, step-by-step guidance. I’m asking how to use the endpoint securely, in general, from the browser.
2FA typically works like 1) verify username & password, then 2) verify 2FA code. Let’s say we’re using a JWT authentication plugin that has a REST endpoint for verifying username & password and responds with a JWT access token. We request that endpoint from the browser and successfully verify username & password. Should the user be logged in at that point? No, because they haven’t verified the 2FA code yet. So they shouldn’t get an access token yet. They need to pass 2FA first.
But we can’t enforce the extra 2FA step in the browser. That would allow the user to just run some JS code to work around it. 2FA needs to be combined with the username/password verification and enforced in the server.
It seems to me like your 2FA plugin would need to be integrated with the JWT authentication in the server. Is that correct? If so, can you share a generic example (not code just a high level flow) how this new endpoint can be used to implement 2FA securely in a headless WP?
If we have to integrate WP 2FA with the JWT plugin ourselves in the server, are there functions and hooks available in WP 2FA for this? Can you share which ones?
-
This reply was modified 3 months, 3 weeks ago by
ryan.boder.
Hello @ryanboder
The WP 2FA plugin does not verify the username and password of a user. The way 2FA works in this case is as follows:
- User navigates to the login page
- User enter the credentials and clicks login
- WordPress checks / confirms the credentials
- If the credentials are correct, the user is authenticated. However, if the user has 2FA configured, the authentication process is halted and the WP 2FA expects the one-time code or a confirmation from that user (the second factor).
- The user submits the one-time code / approves the request
- The WP 2FA plugin confirms the code.
- If the code / approval is correct, the login process is completed and the user’s session is created and the user can access the authenticated area.
So in your case, you only need to interact with the WP 2FA REST API to verify the 2FA code. For the rest of the login and authentication process, you need to interact with the WordPress REST API. You can refer to the Authentication section in the WordPress REST API documentation for more details.
I hope the above helps.
So it is integrated with login on the server side but only with standard WP cookie-based authentication. Correct?
It sounds like this new endpoint would only work with a normal WP site, not with a headless WP site (where the frontend is hosted on a different server/origin). A headless WP site would typically use some kind of token-based like authentication (oAuth or JWT) for cross-origin requests instead of cookie-based authentication.
I was hoping it would be applicable to headless WP sites.
Hello @ryanboder
The plugin works on headless WordPress setups; that is why we included the REST API because it allows for more integration possibilities. However, the plugin has got nothing to do with the “token-based like authentication” you are referring to.
That is something different, that has to be done regardless when sending the REST API request, in the HTTP headers, and it is not something that is dependant on our plugin, or that our plugin has an impact or effect on.
That is required to authenticate when sending a REST API request, and that is handled by WordPress core and not our plugin.
I hope the above helps.
