WebAuthn/passkeys/Direct email login support?

[Anders Pitman]

Any chance of WebAuthn/passkeys support being added to vouch?

Also, my use case requires that users be able to log into my auth server directly by verifying an email address (server sends email with code, user enters code). I recognize this is somewhat out of scope for the way vouch currently works, but if I were to implement it would it be something you would like merged?

[Benjamin Foote]

@anderspitman it's an interesting notion. I'm not sure if this is a good fit for VP but I'm willing to explore it.

Could you flesh out the concept a bit with a flow diagram or at least a very good description of the flow showing what roles each entity (VP, your service, the authenticating service, the browser, the user's MFA dongle/yubikey) would play and how Vouch Proxy would verify the credentials offered? I assume VP is the Relying Party in this setup, yes?

When you say "my auth server" do you mean a service that VP would interact with or do you mean a version of VP with these additional features?

If it could be generalized to follow a very vanilla flow such that other FIDO authenticating services could be used that would be ideal, similar to how provider: oidc works for most Open ID Connect services.

Do you have experience implementing a FIDO service? I have not done that.

I wonder if the best solution would be for you to create a FIDO authenticating server that manages user login (authn) including email verification and offers an OIDC interface to VP. You would get the MFA and email auth you're looking for and VP would "just work" as it does now.

I found this helpful...
https://fidoalliance.org/fido-and-federation-protocols-tech-note/

[Aaron Parecki]

I am inclined to not add any direct authentication mechanisms into Vouch, as that effectively turns it into an IDP and is responsible for managing credentials and managing access.

[Anders Pitman]

@bnfinet, I'll try to answer your questions below if you're interested in continuing the conversation, but @aaronpk's answer made me realize that although VP is close to solving my short term problem, eventually I'm going to need something that acts as an OIDC (and maybe SAML) provider, so I'm probably going to need to use/build something like Keycloak/Authentik. If ya'll have any other suggestions I would definitely appreciate that as well.

@anderspitman it's an interesting notion. I'm not sure if this is a good fit for VP but I'm willing to explore it.

Could you flesh out the concept a bit with a flow diagram or at least a very good description of the flow showing what roles each entity (VP, your service, the authenticating service, the browser, the user's MFA dongle/yubikey) would play and how Vouch Proxy would verify the credentials offered? I assume VP is the Relying Party in this setup, yes?

passkeys support would be nice to have, but email is the critical thing for me currently. The flow is pretty simple. It's basically the Slack "magic link" flow. User enters their email address, VP uses configured SMTP credentials to send an email with a code and redirects to a confirmation form, user copies the code from the email and pastes it into the form, and they're considered logged in and a session cookie is created.

I actually made a nascent auth server that implements this. If you're interesting in playing with it you can get the OIDC configuration here:

https://lastlogin.io/.well-known/openid-configuration

It essentially implements the no-registration clients explained by @aaronpk here: https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web

So the client_id just needs to be a URL that's a prefix of redirect_uri, and you don't need a client secret.

You can test it with something like https://openidconnect.net/ or https://forum.indiebits.io/ by logging in with the LastLogin.io option.

When you say "my auth server" do you mean a service that VP would interact with or do you mean a version of VP with these additional features?

VP with additional features

If it could be generalized to follow a very vanilla flow such that other FIDO authenticating services could be used that would be ideal, similar to how provider: oidc works for most Open ID Connect services.

Do you have experience implementing a FIDO service? I have not done that.

I don't either, and my understanding is that it's fairly complicated. It would be fun to implement, but I'm not a security expert so hesitate to think it would be a good idea.

I wonder if the best solution would be for you to create a FIDO authenticating server that manages user login (authn) including email verification and offers an OIDC interface to VP. You would get the MFA and email auth you're looking for and VP would "just work" as it does now.

That would certainly be an option, but I don't like the complexity of having 2 servers running if it can be avoided. I think at this point the work of adding VP-style forward auth support to my lastlogin server would probably be easier. Problem is I would prefer to start with something that's already battle hardened rather than introducing yet another OIDC server.

I found this helpful... https://fidoalliance.org/fido-and-federation-protocols-tech-note/

👍