Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sick of spending time on Auth, we built an open source 'Stripe for Auth'

news.ycombinator.com

Post reply on HN
Print view View original

301–310 of 347 posts

Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'

#301

Post by iKevinShah »

pelasaco wrote: post #298
pchm wrote: post #293

Earlier quoted context omitted.

Implemented this recently in my SaaS app, replacing passwords with magic links and it was a mistake. Sure, it has some obvious benefits: it forces users to always provide a valid email and logging in confirms that the email address is valid, without any additional logic. But moving auth logic to email links has increased my customer support work significantly: "I can't log in", "I didn't get the link" complaints are…

I was bitten by this issue already two times. First time wth magic links via email. Suddenly your application depends on the mail infrastructure that sometimes is hard to "scale on demand" or even isn't under your control. Second time with OTP via SMS. Both incidents led us to be unreachable for long periods of time, and the SLA provided by our mail provider and telecom weren't really known until the incident. We ass…

Quality insight from someone who has actually gone through this. Thank you!

If you could share, can you share what exactly led to the discovery that things are unreachable. Were there any status check mechanisms you were able to put in place to check that incident was raised and / or solved?

Also, do you still continue that (Email login / OTP login) OR is it moved something else?

Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'

#302

Post by mattatkeyboard »

Not the same thing, as I'm only ever being the Auth client, but I use the approach I documented at https://github.com/forbesmyester/esqlate/issues/5#issuecomme... .

The nice thing about this is that everything behind the NGINX load balancer you don't have to worry about the users being authenticated and / or not.

If you need roles / permissions / metadata you can roll that into your one piece of software which handles the client side auth.

For something small scale, it's perfectly viable to run it all in a `docker-compose`... For something bigger, I've been hosting it on K8s.

Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'

#303

Post by lukeramsden »

tialaramex wrote: post #261
munchbunny wrote: post #22

Interesting idea! I did a quick look through your site and have a few issues: 1. What MFA methods do you support? TOTP? App based auth? U2F? FIDO2? (FIDO2 USB? BLE? Platform authenticators?) Smart cards (especially for enterprise)? Backup OTP's? New device detection? 2. Your docs mention not playing nice with password manager autofill by default. Are there plans to address this? 3. Password reset emails come from @su…

Note that WebAuthn (the standardized replacement for U2F, you should not deploy U2F today) is deliberately designed to authenticate to the site you're actually visiting. It is possible (but not necessarily in all browsers) to override this and authenticate to an iframe for example to allow a third party to authenticate but this creates yet a further problem to deal with: Now you've got WebAuthn's anti-phishing protec…

This would only be a threat if you're using the SaaS, right? If you self-host the user is still authenticating directly with your services, it's just that your services run a pre-made solution on the backend.

Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'

#304

Post by arcturus17 »

ehutch79 wrote: post #196
ehutch79 wrote: post #195

Earlier quoted context omitted.

I'm definitely not questions if your doing things securely or not. Just if maybe needlessly complex. I'll describe what i'm doing, as the code is kind of old. * I have a token model that stores a uuid and the relevant user and data, along with an expiration. This isn't session data, just the valid token. You can also store this in redis or wherever. * There is an endpoint that takes a username and password, and if va…

on the front end i just hit that check_token endpoint every five minutes or so. I'm really not sure that a refresh token on the front end actually provides that much security. Also, this is all just one way of doing it.

We're talking about simplicity, but the solution you outline sounds to me at least as complex as what I implemented, if not more...

I installed two popular libs, tweaked some code in the back, rolled out my front-end, and came up with a robust solution. In my opinion, I wouldn't have saved any time implementing your proposed design if I understand it correctly (especially on the front-end), and I'm not sure about its overall robustness since I don't like at all the idea of periodically polling from the front-end to check the state of the token, as opposed to automatically attempting a refresh on certain response conditions. But that's just me...

Regardless, my original point is that one shouldn't be spending much time at all on a commodity feature like this. I wish I could've spent 80% of that time writing real business logic and interfaces.

> I'm really not sure that a refresh token on the front end actually provides that much security.

Compared to any other mechanism where tokens are revokable (ex: hitting the db), no, it doesn't provide additional security.

Compared to non-revokable tokens it provides loads of additional security, without compromising on UX... The refresh token allows for short access token lifetimes (I have them at ~5min, same as Google has on Firebase), while providing the possibility of keeping the user logged in for weeks and having a revokation mechanism if it all goes south.

Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'

#305

Post by advaitruia »

arcturus17 wrote: post #159
advaitruia wrote: post #144

Earlier quoted context omitted.

If you remember what you had to tweak for Django JWT auth - please do share. It would be interesting to hear your experiences. In terms of implementing the react frontend, this is a common complaint: We do have a react SDK that provides React components for login / sign up UI and its one of our powerful differentiators. It also does not need redux since the login components can handle state easily within themselves.…

Sure, dj-rest-auth + simple-jwt implements JWT with http-only cookies by default, which I have embraced. Except that when you refresh the token, it no longer returns and http-only cookie (it returns the access token in the response body) due to an issue with how the two aforementioned libs interoperate. So the dev has to patch that in manually with their own code, otherwise the full token cycle is not http-only. Isn'…

Yes, that sounds pretty strange - thank you for sharing. Haha yes, it is surprising on the face of it. But when you think about it, its not trivial to make that everything is seamless for all use cases. It requires a lot of time and constant iteration and feedback. Being a maintainer is anyway not easy and when you have the entire framework to maintain, these things happen more often than not.

On the frontend side, we have two libraries - supertokens-auth-react and supertokens-website. The supertokens-website repo deals with sessions (interceptors to axios for refresh + race condition synchronisation). On the other hand, supertokens-auth-react provides login / sign up UI + session management (it uses supertokens-website).

Thank you for the commendation! Would love to hear your feedback. Please do drop me an email on: advait at supertokens.io

Cuídate! (love Spain, have several friends and have visited barcelona, majorca, Sevilla and more)

Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'

#306

Post by advaitruia »

advaitruia wrote: post #174
headmelted wrote: post #171

“We couldn’t afford to pay It took too long to understand the documentation of alternate service providers” These don’t seem like good reasons and would be enough to make me not want to use this until it already has a lot more real-world usage from others first.

Thank you for your candid feedback. Those reasons were also echoed in our user research as we were dedicating ourselves to the project. Could you please share why you think those arent good enough reasons? Ofcourse, social proof is important regardless. SuperTokens is being used in the real world, in production. Would you like to see more people using it or some recognizable entreprise brand names?

Actually we offer the most secure way of managing session tokens. We were the first provider to implement token theft detection using rotating refresh tokens (and most still dont). Auth0 even uses one of our libraries for solving for edge cases. I dont think that good security = complex documentation. Its about the way you abstract away the complexity.

Will factor your feedback when we design the website and think about communication.

Please do let me know when you've had a chance to check it out. Would be happy to hear your feedback

Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'

#307

Post by ecmascript »

This looks very cool and I could use it but I would be more happy for an EU version of this where I can simply pay you for hosting it for me, at least until I know my app or project is successful. I think there is a room for a Plausible version of auth. I think it's good that you offer to self-host it but honestly that is a bit of work as well.

I use a js-only backend so installing Java as a dependency maybe isn't the biggst deal but it's still something I will have to consider.

Even if it's more work to configure and setup an auth myself I will know the intimate details of how it works and don't have to spend time learning another tool in another language. Both takes time and since I've implemented auth several times already it isn't that big of a deal for me.

Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'

#309

Post by advaitruia »

anonymoushn wrote: post #264

I guess not, since it's for nodejs only. I would use it if it had a frontend component and instructions for implementing the backend component.

We do have a frontend component as well as instructions for implementing the backend. Currently we support login for nodejs and session management is supported for several frameworks. We will be adding login support in the near future

Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'

#310

Post by pelasaco »

iKevinShah wrote: post #301
pelasaco wrote: post #298

Earlier quoted context omitted.

I was bitten by this issue already two times. First time wth magic links via email. Suddenly your application depends on the mail infrastructure that sometimes is hard to "scale on demand" or even isn't under your control. Second time with OTP via SMS. Both incidents led us to be unreachable for long periods of time, and the SLA provided by our mail provider and telecom weren't really known until the incident. We ass…

Quality insight from someone who has actually gone through this. Thank you! If you could share, can you share what exactly led to the discovery that things are unreachable. Were there any status check mechanisms you were able to put in place to check that incident was raised and / or solved? Also, do you still continue that (Email login / OTP login) OR is it moved something else?

> If you could share, can you share what exactly led to the discovery that things are unreachable.

We have some heavy monitoring with InfluxDB and Grafana built in our application and one of the alerts is if the number of logins/minute drop under a threshold. That's how we noticed it first time. The main reason was some network issues affecting our mail server provider. We were holding on a support ticket with our provider while trying to find a solution to our customers.

After that we added as well we extended this monitoring to the mail queue. To be fair we used to monitor it before, but with the infra team, now we have it in our SRE dashboard, with Slack notifications and etc.

> Also, do you still continue that (Email login / OTP login) OR is it moved something else?

The OTP as second factor of authentication is something that we couldn't disable, but it's a requirement for one very specific application. We just looked for different partners with better SLA and built some monitoring around it.

The Email login is still there, but we didn't roll-out it to all our applications as we initially intended to. We are still studying what would be the best solution here. The company is heavy user of microsoft's 365 mail service, and although the overall experience is pretty good, we have 0 influence in their SLA if we get impacted by any issue on their side. I don't think that the solution is bad per-se, just you have to plan mail infrastructure as core part of your application.

Post reply on HN