Support Authentication "Challenges"

[mrfrase3]

Just throwing down some thoughts...

Looks like feathers doesn't support 2FA very well. (cough #1601 cough)
In fact, sometimes authentication requires several steps, like email/phone validation or suspicious login requiring a reCaptcha.

What would be nice is taking a generalised approach for the backend to "challenge" someone's login request.

Basically, when doing normal authentication, flag the login as needing a challenge, and instead of returning a fully-fledged accessToken, instead return a challenge JWT, which is then returned when calling authenticate again with the strategy being the challenge.

Something like:

Client --> { strategy: 'local', username: 'bob', password: 'Password123' } --> Server
Client <-- { challengeStrategy: 'sms', challengeToken: '...' } <-- Server
Client --> { strategy: 'sms', challengeToken: '...', code: '123456' } --> Server
Client <-- { accessToken: '...' } <-- Server

What would also be cool is feathers having "out-of-the-box" support for Authenticator App 2FA.

[tvld]

Indeed 2FA would be valuable to get "out of the box" in feathers.

..Just like other two-step changes such as password reset and signup confirm emails. And these we implemented ourselves with hooks:

• Instead of just for example setting a new password, we catch the request and create a "confirmation" document.
• The actual change is only later initiated when the server receives a get on the /confirmation path using the appropriate _id of that confirmation doc.
• Time limits and some extra salt/hash harden the process a bit more.

The advantage of this method that we can use it for any kind of two-step approach, email confirm, 2FA and others. And it is not anti-pattern to feathers, I think...)

[mrfrase3]

Few extras:

1. maybe the server response is an array of potential challenges, e.g challengeStrategies: ['sms', 'email', '2fa'], this allows the user to choose how to respond to a challenge with their several 2FA's

2. If the user checks "don't ask again for x days" checkbox, the client could store some "completed challenge JWT" or something?

i.e.

Client --> { strategy: 'local', username: 'bob', password: 'Password123' } --> Server
Client <-- { challengeStrategies: ['sms', 'email', '2fa', 'completed_jwt'], challengeToken: '...' } <-- Server
Client --> { strategy: 'sms', challengeToken: '...', code: '123456' } --> Server
Client <-- { accessToken: '...', completedToken: '...' } <-- Server

// a few days later
Client --> { strategy: 'local', username: 'bob', password: 'Password123' } --> Server
Client <-- { challengeStrategies: ['sms', 'email', '2fa', 'completed_jwt'], challengeToken: '...' } <-- Server
Client --> { strategy: 'completed_jwt', challengeToken: '...', completedToken: '...' } --> Server
Client <-- { accessToken: '...' } <-- Server

[mhillerstrom]

I think this would be very useful approach.

[J3m5]

IMHO, there are software (Saas or self-hosted) that handle that well and which follow the OpenID Connect/OAuth2 protocol that are standards now.
Those solutions has all the features you could need: refresh tokens, session/token revocation, groups/clients, user federation with ldap, roles, logging authentication flow, email change, password reset, password policy, user registration, OTP/WebAuthn auth, external identity provider and more.

[mrfrase3]

I've kinda got a pretty sour taste in my mouth after using firebase and then cognito, I end up having to roll a custom implementation of most of those features because those services don't quite offer the features we need for the business, e.g. we want to send emails in the same template/branding as the rest of our backend communications.

At this point, Cognito for us is just an over-glorified and really complicated password store...

[J3m5]

Then you should give Keycloak a try, you can customize the email templates and it has everything I mentioned.

The big advantage to me is that you have one service that do the authentication that can be reused in almost any other projects, with or without a front-end, so you don't have to reconfigure/re-implement each time.

You can even externalize the jwt verification at the reverse proxy level with the caddy-auth-jwt plugin or oauth2-proxy.
Once done, you can be sure that all the request that hits your servers are already authenticated and thus you don't have to care about authentication at all.

[daffl]

I've been thinking about what a good flow for 2-factor verifications, the problem is that it has a long tail of other things you will have to set up (authenticator, SMS or email service, a protected URL to render the authenticator QR code and probably a bunch more).

I still can't shake the feeling that by now the whole authentication space in general has become so complex that it is almost impossible to cover it all in an open source project. Firebase and Cognito are run by the two most valuable companies in the world. Auth0 addresses basically most of the exact same problems and recently sold for 6.5 Billion (!) dollars. I mention this because it kind of gives a reference to the scope of the problem space (even if individual features might look easy to implement).

Personally I'd love to throw all that legacy cruft out of the window and just provide

• A way to create and verify a JWT and leave everything else up to the developer or a third party service
• Focus on public/private key authentication (especially now that all decent browsers support the web crypto API). This is unfortunately still a bit out and also has its own challenges (i.e. how to manage keys securely outside of the browser).

[mrfrase3]

If I had to put my finger on it, auth is something developers don't want to deal with when starting a project and they will go with one of these services to shave off time towards an MVP. That's how they get you, because switching services is really difficult and it becomes baked into your application.

There's always going to be a variety of factors from project to project that make implementing auth for each a special snowflake combination of features, the complexity of these large services is in them trying to provide a solution for everyone, and always getting 80% of the way there. I started getting a migraine looking at the docs for keycloak above, and gave up when I realised I would have to write code in java to make it work for us. (I just want to implement 2FA)

I think the simplicity of the auth strategies, and hopefully challenges, allows a developer to implement whatever they want, I don't think feathers needs so implement all or even any of the challenge strategies.