Is there a sample project in Xojo that I can reference to walk me through how to add MFA to my xojo web app?
for extra 2FA
usually you have a server like LinOTP or Keycloak/Single Sign-On (at companey)
for Multi-Factor Authentication then use theirs api methods.
this kind of software support often MS Authenticator, Google Authenticator, and some others.
i guess paid online services exists too but i not used myself.
implementation could be effortful.
question is what Multi authentication ways you will use.
something simple extra would be send a random code or link to mail address
and then use this time-limited link for login to your page.
something you have to consider is if the customer is at pc he maybe read the mail at phone.
thats why often a code is used for read at phone and manual input at other device.
I am considering two options for them to choose from:
-
sms to their phone
-
a code sent to their email address
I like it when a website asks me for my email. And then in the email is a one time link with some secret code.
Like when I click login on the website, you generate such a random code and store it in the user record and send it in the email. Then when I click on the link, it has my random code as well as some other code like an UUID to find me in the database.
The user clicks on the link and is logged in.
PS: Donāt use the real record ID for user in the link.Something random and unique.
@Keith_Keller, but also consider the use of passkeys which is now baked into Xojo web. See New WebUserAuthentication Control: Look, Mom, No Passwords! ā Xojo Programming Blog .
In respect of two-factor, we prefer OTCās sent via email, as browsers will often try to populate the code directly from a users email, which makes for a better user experience.
Kind regards, Andrew
I have GraffitiVerificationKit, which handles generation, sending, and validation.
With the SMS option, the user may have to provide their private mobile phone number.
The email option may be delayed. If the website is only being used on a mobile device, switching to the email app and back can be cumbersome.
If someone is using a website on a PC, they should not be forced to use a second device to access their emails.
we should kept the right having no smart phone.
you are in the IT business, let a housewife (with less pc experience) or older people do this procedure and watch 
My plan is to offer each as an option for them to choose which they want to go with.
Iām the opposite because itās slow. In the time it takes for the email to arrive - even if itās only a few seconds - my password manager could have completed the login multiple times. āEmail to loginā, āemail as MFAā, and ātext as MFAā are all āfeaturesā I ravenously try to turn off. Unfortunately, not all providers offer such a thing.
@Keith_Keller Email/Text as MFA is fine for some people. I personally hate it. My preferred option is passkeys, second choice is TOTP. But my real point is people have different opinions, and new techniques still get introduced. Come up with a plan so that you can offer other options in the future. Maybe you start with email as MFA, then add TOTP later.
Another thing to consider about using email as a second factor is that itās very commonly also compromised. MFA was designed to combat password reuse only. If somebody has used the same password for their email and your system, email-based MFA provides no additional security since the attacker has access to both. And unless youāre storing passwords poorly, your system is not likely to be the breach point. The most common attack plan goes like this:
- Attacker finds user credentials for SomeSite.
- Attacker tries those credentials at the email provider. Some succeed.
- Attacker finds Apple, Google, Microsoft, Sony, Meta, Steam, etc. emails and attempts password resets.
- Attacker buys gift cards.
You are āSomeSiteā in this scenario, so your goal is to stop step 1. For example, not only am I hashing passwords, I hash my email addresses too. MFA is a good thing to offer - I offer it to too - Iām not trying to talk you out of it. But if somebody is trying to attack your userās account via a password reset after compromising their email, that email-based MFA will not protect them.
Well, it would be great if someone implements Passkeys in JavaScript for Web apps.
Yeah I did passkeys very recently for normal JavaScript. They are quite a pain thanks to some odd bugs. For example, there is a feature that allows you to automatically create a passkey for the user and instruct their device to save it. Safari advertises that it works, but when you try to do so, the function just hangs and thereās not a thing you can do about it. I even tried to add a timeout and abort handler to cancel the request, but that wouldnāt do it either. So ultimately I had to leave that off or else some users wouldnāt be able to log in unless they already had a passkey.
Getting them implemented for Xojo Web is probably a task best left for @Anthony_G_Cyphers to add to GraffitiKit. Iāve been out of the Xojo Web game for so long that I know very little about what the modern framework looks like.
Great point!
And to top it off, I have to test across multiple browsers that my users use.
Firefox
Chrome
Edge
Safari
Brave
Vivaldi
I came to realize a few years ago that assuming those that inherited from Chromium only required me to test on Chromium or Chrome, but I quickly realized that there are times when results differ.
Passkeys are already supported in Xojo Web through WebUserAuthentication since 2025r3:
Oh. Well there you go. Passkeys are ā ā ā ā ā ā ā awesome.
@Thom_McGrath , @Ricardo_Cruz , and othersā¦ can anyone share what a workflow might look like for a Passkeys-only login scenario? Weāre working on a new project and Passkeys might be an easy solution to secure their WebApp access.
Hereās what Iām envisioning (and where I hope to solicit better ideas)ā¦
- WebApp (client) admin uses UI to create a new account āusername@theirdomainā, assigning them to their role etc., along with some form of temporary password, preventing a 3rd-party from hijacking the account before registration takes place.
- A traditional āWelcomeā email is sent with login instructions.
- The new user visits the login page, enters the account details sent to them by the app, and is ran thru the Passkey Registration process. The WebApp stores this data in the account created for them. Logic in the app determines if the user is allowed access, and all role-based security behaviors.
- WebApp logic controls if the user can (or canāt) create multiple Passkeys against this app.
- Users losing their Passkey send admin a message to reset their accounts, where admin deletes the credential and resets their temp password.
Only on my first 
and looking forward to trying my hand at this today. Thanks for any advice to help with the best implementation
Sounds about right. My only red flag is allowing the user to reset their credentials. How do you verify their identity? If itās a closed / in-house system, your plan is fine. But for an open registration, if somebody were to compromise the userās email account, how do you verify the person and not just the email?
Thatās a tough problem to solve, and the general advice is donāt. For example, if you lose your GitHub 2FA credentials, they will not remove those credentials from an account under any circumstances. The account is lost. Youāre able to switch email addresses around so that you can use the same email for a new account, but the only way into the old account is with the correct credentials. And this is because Microsoft doesnāt have any way to identify the person with 100% certainty. If it turns out the request was not legit, they can get your email reattached to the original account. Itās harsh and frustrating, but it makes sense.
That said, GitHub holds code that for many is their entire business. Allowing somebody to break in would be catastrophic. Most accounts donāt need that level of security.
But just wanted to throw that out there: have a policy for lost credentials and identity verification.