i'm designing a 2FA OPT feature for an app that lets users book flights and trains. As users are able to store personal information including their payment details, this level of verification is needed.

At 1st it made sense to include this at the beginning, just after users log in, similar to banking apps. However i'm considering including it in just the parts of the app where sensitive information will be accessed. this way it might not be such a hassle for users accessing features on the app what doesn't have personal information. what are your thoughts? are there any other solutions?

  • Is this an actual app or a website? Also, shouldn’t users remain connected, so as to have direct access to their preferences, history, and so on?
    – jcaron
    Commented Feb 14, 2020 at 8:30
  • @jcaron Read the question. It says app
    – Blue Ocean
    Commented Feb 21, 2020 at 5:14

4 Answers 4


Since this is the UX StackExchange, I will answer around the user experience concepts associated with F2A.


Applications have F2A authentication to protect a user from identify theft and monetary theft and the company from legal action for Personally Identifiable Information(PII) being released. Skipping F2A or OTP for verification is simply not an option with the sensitive information the app contains: payment info, PII data. While F2A is not a legal requirement, it is a great tool for fraud prevention.

That said, likely there are portions of the app that can be explored without displaying PII or offering the option to purchase, such as looking at train/flight times, locations available, or pricing. These should be available without the need for any authentication.

This alone would lead to a recommendation that F2A authentication is reserved until the point when a user would be accessing PII or ready to start the payment process.

Ease of Use

Best to make things easier for your users whenever possible and unfortunately, F2A is an extra step. As an extra step it should be reserved for when it is truly necessary and not introduced earlier. If a user can avoid it altogether, their use of the app will be easier.

Another aspect of ease of use is flexibility and options. Give users options for F2A or OTP or using biometrics if it is an option. And as James Coyle mentions, flexibility in payment options is a win for the business and the users: the business can defer security to the payment providers and the users have options to select the payment method they prefer.

Perception & Emotion

This will require some research to understand the best approach. F2A protects users, but there is also the perception of protection to consider. Do users feel uncomfortable with not having been prompted to authenticate right away or did they not even notice/care? How far can the application go without asking for F2A before users start to feel uneasy and ask a test facilitator "Shouldn't the app be asking me for login info?"

Targeted user research will help answer these questions. Combine the perception with the need and ease of use to determine the right time to ask for F2A.


I would use 2FA on login if the user has enabled it. 2FA can be annoying for users so get it out of the way up front at login where a user would expect it to be and keep the user logged in. You can always ask for 2FA authentication again if the user hasn't provided it in a while and they need to do something which requires extra security. Remember that you aren't a bank and don't need to log the user out all the time to ensure security so you can ask once and keep the user logged in.

Allow standard OTP authentication via an authenticator app; biometrics such as fingerprint, face, or iris scan; and an email OTP backup. Only require one of these but give your user a couple of options. Biometrics are preferred on mobile as they are usually quick and easy so it's best to default to that if the user has enabled it. OTPs are easy to use but are more annoying as you have to open a separate app to retrieve the code. Finally, a link which sends the user a one time login link in an email allows the user to gain access to their account even if they have lost their mobile device which would be important for a travel app.

One thing to consider is how you're managing your payments. It may be better to use payment APIs of the devices you are targeting (such as Apple or Google pay) or redirect the user directly to the third party payment services to complete the transaction. You are then leaving the security of those transactions up to the providers that have a lot more resources to pour into security. This may also help your customers feel more comfortable completing a purchase on your application as the transaction is going directly through a service they are familiar with.


"As users are able to store personal information including their payment details, this level of verification is needed."

Actually, it should only be needed if/when something strange/unusual/out-of-the-ordinary happens regarding the account that has authenticated with a single factor. I.e. 2FA OTP is an annoying step, it is slow and prone to problems (like travelling in another country with a travel SIM while account is locked to the SIM sitting in a drawer back at home). It does provide an extra layer of security though, but that is only necessary sometimes.

Accessibility (WCAG 2.0 Level AA) is an important compliance baseline for the aviation industry, particularly in ticketing systems. Consider whether your 2FA approach will work for those kinds of Users, otherwise fail miserably and get sued.

"similar to banking apps" suggests you are "shallow copying" based on perceived behaviour of a UI interface, that is a really bad approach when security controls are involved: because security controls attempt to be hidden and systems should not divulge their inner workings. You should take direction from your security team or a trusted adviser who is skilled in application security.


Technically 2FA is part of the login process. The token is required to generate a fully certified authentication (user is who they claim to be). And thus should be requested as part of the login process. You can't separate them since that would mean the user isn't actually logged in.

The real question in your case is NOT when to include 2FA but when to force the user to login, to begin with. Can you store some preferences locally on the device that might not be security risks? Eg seating preference, meal preference, favorite/home departure city, could all be stored as useless information if the device is shared or compromised.

Then you would only need to request authentication when its time to make an actual transaction.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.