JSON API does not support TFA (Multi Factor)?..

[Dennis O'Connell]

Hi,

I have created an user and also setup OTP. When I logout and login back via Browser (HTML) after I enter my password, system asks me TFA Code. Good.

However, When JSON API request made using username and password, I just get log in :(

Does JSON support  TFA auths? If so why am i not asked for TFA. If not how can I simply enable or replicate this behavior just like in HTML Views?

P.S.: I've also enabled JWT-related plugins.

Thanks,

-Den

[Jeremy Evans]

On Sun, Nov 21, 2021 at 2:06 AM Dennis O'Connell <denniso...@gmail.com> wrote:

Hi,

I have created an user and also setup OTP. When I logout and login back via Browser (HTML) after I enter my password, system asks me TFA Code. Good.

However, When JSON API request made using username and password, I just get log in :( 

Does JSON support  TFA auths? If so why am i not asked for TFA. If not how can I simply enable or replicate this behavior just like in HTML Views?

The JSON API in Rodauth is handled almost exactly the same as regular HTML, by design.  The only difference is JSON doesn't not automatically redirect., you need to have your front-end submit the request to the otp_auth route after logging in.   If you are logging into an TFA-enabled account via JSON, after login, you are considered logged in, but you are not considered fully authenticated (rodauth.authenticated? returns false).  This is the same behavior after HTML view login, if you try to navigate away after logging in but before submitting the OTP code.

Thanks,

Jeremy

[Dennis O'Connell]

Hi Jeremy,

Now this makes sense. However, the thing that confuses me was that there was no any message or code that asks me to send request to TFA.

After user successfully logged in, how do I know if TFA required or not? Is there any api endpoint to check this? Because response just says "user logged in".

Thanks,

-Den.

[Jeremy Evans]

On Sun, Nov 21, 2021 at 9:19 PM Dennis O'Connell <denniso...@gmail.com> wrote:

Hi Jeremy,

Now this makes sense. However, the thing that confuses me was that there was no any message or code that asks me to send request to TFA.

After user successfully logged in, how do I know if TFA required or not? Is there any api endpoint to check this? Because response just says "user logged in".

Currently, I don't think there is one.  It's not hard to add yourself using rodauth.possible_authentication_methods, but I think it's reasonable to expect that Rodauth would have such an endpoint.  I'll add that today.

Thanks,

Jeremy

[Dennis O'Connell]

Hi Jeremy,

I'll be (and many users im sure) very happy to have such feature. Thank you for your quick reply and solution. 👍 Because I tend to rely on full JSON API instead of implementing my own auth flow. It will be much more easier for many users including me to check extra endpoint if extra verification is needed or not. (Perhaps what will be needed can be added as a response such as TFA/SMS etc.. first)

-Den.

[Jeremy Evans]

On Mon, Nov 22, 2021 at 8:44 AM Dennis O'Connell <denniso...@gmail.com> wrote:

Hi Jeremy,

I'll be (and many users im sure) very happy to have such feature. Thank you for your quick reply and solution. 👍 Because I tend to rely on full JSON API instead of implementing my own auth flow. It will be much more easier for many users including me to check extra endpoint if extra verification is needed or not. (Perhaps what will be needed can be added as a response such as TFA/SMS etc.. first)

I'm going to implement the support by allowing JSON requests to the multifactor-auth and multifactor-manage routes.  These will return links to endpoints for supported multifactor authentication or setup/disable.  This mirrors the authentication flow that the HTML interface uses.

Thanks,

Jeremy 

[Jeremy Evans]

Support committed: https://github.com/jeremyevans/rodauth/commit/f7a8acbc8c9a2625c584fb1c60bde903b8c3f038 

Thanks,

Jeremy

[Dennis O'Connell]

Hi Jeremy!,

WOW! Thank you so much. That was faster than I can imagine!

I'll test the endpoints on my end using `master` branch ASAP. And hope you can release a new version soon for this.

[Jeremy Evans]

On Mon, Nov 22, 2021 at 9:06 AM Dennis O'Connell <denniso...@gmail.com> wrote:

Hi Jeremy!,

WOW! Thank you so much. That was faster than I can imagine!

I'll test the endpoints on my end using `master` branch ASAP. And hope you can release a new version soon for this.

I was thinking about a release tomorrow, so if you can get the master branch tested today and provide feedback as to whether this works for you, that would be great.

Thanks,

Jeremy

[Dennis O'Connell]

Hi Jeremy,

Here are the results. After /login as usual:

Endpoint: /multifactor-manage

Response: 401 - You need to authenticate via an additional factor before continuing

Endpoint: /multifactor-auth

Response: 200 - Links: ["/auth/api/v1/otp-auth"]

So, The rest is to visit that OTP link and request a code from client as expected.

What if user does not have OTP/SMS?

Endpoint: /multifactor-manage

Response: 200 - /otp-setup link given...

Endpoint: /multifactor-auth

Response: 403 - This account has not been setup for multifactor authentication

Is there any other endpoint should I test?

Thanks,

-Den.

[Dennis O'Connell]

Hi Jeremy,

One more thing. Should we have something like this? Or would this break the standards?

Current response:

{

    "access_token": "ACCESS_TOKEN_HERE",

    "refresh_token": "REFRESH_TOKEN_HERE",

    "success": "You have been logged in"

}

Suggestion:

{

    "access_token": "ACCESS_TOKEN_HERE",

    "refresh_token": "REFRESH_TOKEN_HERE",

    "success": "You have been logged in",

    "mfa": true # <-- here. or false if no multifactor required...

}

My previous email contains test results.

Thanks,

-Den.

[Jeremy Evans]

On Mon, Nov 22, 2021 at 9:32 AM Dennis O'Connell <denniso...@gmail.com> wrote:

Hi Jeremy,

Here are the results. After /login as usual:

Endpoint: /multifactor-manage

Response: 401 - You need to authenticate via an additional factor before continuing

This is expected.  If you have already setup multifactor authentication, you need to be multifactor authenticated before you can manage your multifactor authentication.  After all, we don't want someone only single factor authenticated to remove multifactor authentication.

 

Endpoint: /multifactor-auth

Response: 200 - Links: ["/auth/api/v1/otp-auth"]

So, The rest is to visit that OTP link and request a code from client as expected.

Correct.

 

What if user does not have OTP/SMS?

I guess you mean what if the user has not setup multifactor authentication?

 

Endpoint: /multifactor-manage

Response: 200 - /otp-setup link given...

This is expected.  As multifactor authentication has not been setup, the user is fully authenticated after logging in, so the multifactor setup links are shown.

 

Endpoint: /multifactor-auth

Response: 403 - This account has not been setup for multifactor authentication

This is expected as the user has not setup multifactor authentication.

 

Is there any other endpoint should I test?

No, those are the only two added.

Auth flow should be easy to handle.  After login, submit JSON request to multifactor-auth.  If 403 is returned, user is likely already fully authenticated.  If 200 is returned, you can use the auth_links to go to the next step in the flow.  Will that work for you?

Thanks,

Jeremy

[Jeremy Evans]

On Mon, Nov 22, 2021 at 9:36 AM Dennis O'Connell <denniso...@gmail.com> wrote:

Hi Jeremy,

One more thing. Should we have something like this? Or would this break the standards?

Current response:

{

    "access_token": "ACCESS_TOKEN_HERE",

    "refresh_token": "REFRESH_TOKEN_HERE",

    "success": "You have been logged in"

}

Suggestion:

{

    "access_token": "ACCESS_TOKEN_HERE",

    "refresh_token": "REFRESH_TOKEN_HERE",

    "success": "You have been logged in",

    "mfa": true # <-- here. or false if no multifactor required...

}

I don't want to add this, as I don't think it contains enough information to be useful in the general case.  The current approach offers more information and better mirrors in the JSON interface what happens in the HTML interface, and Rodauth tries to make the interfaces the same as much as possible. However, you can certainly implement this yourself using after_login.

Thanks,

Jeremy

[Dennis O'Connell]

>> Auth flow should be easy to handle.  After login, submit JSON request to multifactor-auth.  If 403 is returned, user is likely already fully authenticated.  If 200 is returned, you can use the auth_links to go to the next step in the flow.  Will that work for you?

Absolutely. As soon as I get 403, job is done. Otherwise I'll do all necessary steps on the client side. Of course, If you have a better idea other than this, I'd like to hear it as well. But so far so good and more than enough.

>> I don't want to add this, as I don't think it contains enough information to be useful in the general case.  The current approach offers more information and better mirrors in the JSON interface what happens in the HTML interface, and Rodauth tries to make the interfaces the same as much as possible. However, you can certainly implement this yourself using after_login.

That is the point actually. If we have `mfa` is true, then we have to go those new endpoints and check the required authentication methods. If `mfa` is false then no action is required therefore no second API request can be sacrificed (response time will be lower). Much faster :) But of course, you know this better then me, so, it is your decision in the end.

As I said, first one will work for me. Second suggestion is there to save another request being sent to server. true for another request, false for OK.

Thank you so much for your replies and implementations, Jeremy. ❤️

Thanks,

-Den.

[Dennis O'Connell]

Ah, About ` after_login`, can you give me a little example? How can I append this information into existing response?

Thanks,

-Den.

[Jeremy Evans]

On Mon, Nov 22, 2021 at 10:08 AM Dennis O'Connell <denniso...@gmail.com> wrote:

>> Auth flow should be easy to handle.  After login, submit JSON request to multifactor-auth.  If 403 is returned, user is likely already fully authenticated.  If 200 is returned, you can use the auth_links to go to the next step in the flow.  Will that work for you?

Absolutely. As soon as I get 403, job is done. Otherwise I'll do all necessary steps on the client side. Of course, If you have a better idea other than this, I'd like to hear it as well. But so far so good and more than enough.

Nope, that's basically the same idea I had.

 

>> I don't want to add this, as I don't think it contains enough information to be useful in the general case.  The current approach offers more information and better mirrors in the JSON interface what happens in the HTML interface, and Rodauth tries to make the interfaces the same as much as possible. However, you can certainly implement this yourself using after_login.

That is the point actually. If we have `mfa` is true, then we have to go those new endpoints and check the required authentication methods. If `mfa` is false then no action is required therefore no second API request can be sacrificed (response time will be lower). Much faster :) But of course, you know this better then me, so, it is your decision in the end.

I can see how it makes things slightly faster.  Not sure how it would make things much faster.  The request to login should take much longer than the request to check for multifactor authentication due to checking the bcrypt password hash (or whatever you are doing to authenticate).

 

As I said, first one will work for me. Second suggestion is there to save another request being sent to server. true for another request, false for OK.

In terms of implementing the after_login, maybe something like this (untested):

after_login do

  json_response['mfa'] = !authenticated? if use_json?

end

Thanks,

Jeremy

[Dennis O'Connell]

>> I can see how it makes things slightly faster.  Not sure how it would make things much faster.  The request to login should take much longer than the request to check for multifactor authentication due to checking the bcrypt password hash (or whatever you are doing to authenticate).

Good point, actually :=). Not much, but slightly. I think I will go with current approach. (But will save your example as a reference for later maybe for another usage)

Thank you so much!,

-Den.