For a frontend, i would like to implement MFA (with TOTP). I may be searching for the wrong keywords but i couldn't find the proper way to implement securely this solution. I was searching for a diagram flow for example such as:

  1. Request: POST to /login with credentials in JSON, Response 302 to /mfa
  2. Request: GET /mfa , Response /mfa
  3. Request: POST with credentials again and mfa code , Response 302 to /
  4. Request: GET to /, response 302 to / (user logged in)

Is there any RFC describing (https://www.rfc-editor.org/rfc/rfc6238) in details the implementation of such protocol or its up to the user to sniff other website's ssl to reverse engineer how they did it (which i did for github etc..). Just searching for the correct way to implement it, may be an already working framework? should i use cookies or is it fine to re-request the user and login along with the mfr code ( i noticed github at STEP 3 use authenticity_token=<base64token>&otp=<123456> )

Thanks a lot for your help

PS; already made solution like login with google are not possible, i need to use my own user's db

4 Answers 4


You might want to check out PrivacyIDEA and their product and code - they have a working implementation in python, and I think you could use their API for one or both authentication rounds.


It isn't without a few rough edges here and there (you certainly do not want to let this loose on your user DB without some testing), but might provide you either a service you can use while you research, or a concrete implementation you can base your own off of

  • thanks for your answer, nevertheless, i would rather not rely on third parties as much as i can, i got 4k+ clients, the less i externalise, the better i feel, i just want to rely on technology standards, RFC, OWASP recommendations etc..
    – jthemovie
    Feb 28, 2017 at 17:32
  • Totally understand - I was also pointing to it as a completed example of the kind of login flow you were looking to implement - not necessarily as something you needed to insert into your flow. But that does bring up one point, which is that if you had a 2-step process (rather than a single login page), it might give you more flexibility than having everything on one page. At any rate, good luck Mar 1, 2017 at 9:28
  • 1
    Are you only talking about authentication? Thisis a bit short handed. You need enroll the TOTP devices and manage your devices. You also need to provide mechanisms if a user has lost or forgotten his smartphone. This in handled within privacyIDEA. By the way: privacyIDEA in fact follows RFCs and usual standards like JWT. RFC6238 only defines how OTP is calculated. You simply need to add this during the login process. You can rely on any usual session handling.
    – cornelinux
    Mar 13, 2017 at 18:03
  • 1
    Reading "3rd party" and "externalize" there might be a misunderstand. privacyIDEA is no hosted service. It is an open source software running on your machines under your control.
    – cornelinux
    Apr 20, 2017 at 14:54

How about not having a separate page for the two-factor code?

On your standard login page, have a hidden and optional field for the 2FA code - when logging in do it in Javascript so that it can check whether the account has 2FA enabled, and if so, make the field visible and let the user try again?

This avoids having to remember whether the user has logged in with the password, since on the second try your login request will contain both the password and the 2FA code, at which point you can verify them and grant/deny access.

Gandi.net implements something like this. When logging in with 2FA enabled they return you the same login page with your username/password already there and an extra field for the 2FA code. We can argue that sending back the password isn't perfect (though the attack surface is very small IMO), so that's why I proposed to do it in Javascript, that way the server doesn't have to send back the password, as we simply don't refresh the page and preserve the existing one.

  • Thanks Andre (with this lastname i could try to say Merci but unsure.. :) ), this is the idea i had in mind actually, the problem is that i feel that there is thousands differents ways companies implement 2FA (facebook, github, google, etc...) and i wanted to be able to rely on some standards. I don't want to believe there is no good standards about it and companies goes more or less freestyle hoping it will be secure enough :/
    – jthemovie
    Feb 28, 2017 at 17:29

I think you get something wrong here about two factor authentication with OTP!

Default behaviour

Imagine a web application, which authenticates the user with username and password. Image this is implemented to your needs and you are fine with that. There are standards to do this.

Now: OTP does not change anything with that. You do not change cookies, session, JWTs whatever. With OTP you only add the second factor to the password.

Till then the user entered

  • username
  • password

THis is sent to the application, the application verifies it and returns a session to the user.

Add 2nd factor

When adding a second factor the user enters:

  • username
  • password + OTP

this is sent to the application and the application verifies password + OTP and, if everything is fine returns a session the same way as before. No voodo involved here.

  • Thanks for your comments, nevertheless, i noticed that sometimes instead of sending twice the username/password, they were creating a temporary token, that was send along with the OTP. This way, the username and password were not sent twice to the server. But since i couldn't find any special recommendations, then i agreed to send twice the set(username,password)
    – jthemovie
    Mar 15, 2017 at 12:35
  • Now I understand. You think about adding the second factor in a second step. Of course to "bind" this second step (second factor) to the successful first step you need to have some kind of "session" or we call it "transaction id".
    – cornelinux
    Mar 15, 2017 at 15:57

Regarding your objectives, you might want to consider the process-flow for Multi-Factor as described by PCI-DSS (even though it might not be directly applicable to your situation now, it eventually could one day) in the following document:

Check Chapter: Multi-step vs. Multi-Factor on Page 5

INFORMATION SUPPLEMENT Multi-Factor Authentication Version: 1.0 Date: February 2017 Author: PCI Security Standards Council


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .