> While OpenAuth tries to be mostly stateless, it does need to store a minimal amount of data (refresh tokens, password hashes, etc). However this has been reduced to a simple KV store with various implementations for zero overhead systems like Cloudflare KV and DynamoDB. You should never need to directly access any data that is stored in there.

Written like someone who's never actually maintained an identify provider used in B2B contract work. You will inevitably come into contact with people who cannot make things work on their side and are doing things so unexpectedly that logging is insufficient to track down the error. Sooner or later you will need to look at the data actually in storage to figure out what your customers who are threatening to cancel their contract are doing wrong.

I've been there. Many times.

Can we not call any authentication scheme/protocol/service starting with "Open" and even "O" anymore? We already have OAuth, OATH, OpenID, OpenIDConnect, and Okta; it's getting out of hand.

Cool project!

OAuth-based auth providers are nice, but they can have a weakness. When you have just one app, OAuth can be overkill: protocol is complex, and users suffer jarring redirects¹.

This is not surprising, because OAuth / OIDC is fundamentally designed for (at least) three parties that don't fully trust each other: user, account provider and an app². But in a single app there are only two parties: user and app itself. Auth and app can fully trust each other, protocol can be simpler, and redirects can be avoided.

I'm curious what OpenAUTH authors think about it.

¹ Except for Resource Owner Password Credentials (ROPC) grant type, but it's no longer recommended: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-secur...

² In addition, OAuth is mostly designed for and by account providers, and follows their interests more than interests of app developers.

Good for them for trying! I've been in the auth space for a few years and am surprised that a stateless AWS lambda for doing the exchange. (At least I haven't seen any.) So it is nice to see some serverless innovation.

Thoughts from a quick scan:

- They support PKCE (yay!)

- They suggest storing access tokens in localstorage (boo!)

- They support JWKS (yay!)

https://www.keycloak.org/ is pretty great too, if you need a little more.

Happy to see the effort! Fresh blood in the authn space is always welcomed.

Without rehashing the other good points commenters have made already, I’ll just say that every project starts out immature. What makes a project great is how willing the maintainers will be to grow along with the project and incorporate feedback. I’m excited to see future evolutions of this one.

2024 and we still are not sure how to implement auth. Webdev is fantastic.

Is this like a Passport.js alternative?

https://www.passportjs.org/

Does it only support username/password + OAuth? I didn't see much information on if it supports SAML. I'm interested in how it compares to things like https://github.com/zitadel/zitadel and https://github.com/ory/kratos

How does this compare to supertokens https://supertokens.com/ that supports fastify express, hono, bun, koa, nuxt, react, vue, angular with email password + social login + OTP based login + single sign on all wrapped in a self hostable nice package?

Trying to understand where this fits in to the current ecosystem. Looks like it's sort of like Passport but it runs in a separate server, and apps use OAuth2 to communicate with it? The example video looks like it's only doing authentication. Does it do any authorization? Do apps need to use OpenAuth libraries directly, or can they get back with basic cookies/redirects/etc?

I'm guessing this is for service providers and not identity providers. Just a suggestion, but that could be more clear in the description.

https://youtu.be/mKKx8uXw5ak