Live data from Hacker News

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

news.ycombinator.com

201–210 of 347 posts

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

#201
post #189
post #188

For my little web app I just went with passwordless logins and did the "magic token sent to the inbox" thing. I no longer have to deal with passwords at all; a security breach is (mostly) useless in terms of mining creds; and all of the password handling workflows are now the email provider's problem. If someone loses access to an email account then I can use manual processes to verify the person and change the email…

I had to do this on a recent project because Corporate IT departments sometimes flag anything that has a create account / login prompt with a password field. Once you get on their shitlist it can take months of fighting the red tape machine to get off of it again. So we bypassed that with passwordless login using email. Unrelated, but we also discovered that one corporate had some kind of batshit crazy network where…

Not that uncommon for large companies to bring their IP space in house to multihome and load-balance traffic across multiple providers. If they are routing traffic back to random data centers for centralized filtering, it makes sense how it could be coming from different regions. I'm more interested in what made your application sensitive to this. The duplicate packets does sound bizarre. Maybe a mirroring issue or firmware issue.

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

#202
post #188

For my little web app I just went with passwordless logins and did the "magic token sent to the inbox" thing. I no longer have to deal with passwords at all; a security breach is (mostly) useless in terms of mining creds; and all of the password handling workflows are now the email provider's problem. If someone loses access to an email account then I can use manual processes to verify the person and change the email…

This is a really cool idea.

So they basically go to their email and verify and it stores a token in their cookies?

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

#203
post #161

Wow, that pricing is awesome. Once you have email verification, social login, and a C# SDK, I will switch away from Auth0 in a heartbeat. This being open source is a HUGE draw. It means I don't have to trust you as much, because the code is out in the open for security researchers to poke at. Do you have a bug bounty program? I assume this works via an API as well, not just web based sessions? My use case is an onlin…

You can have all of the things you're looking for with IdentityServer4. No need to wait!

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

#205
Guys, why bother integrating different SDKs for different languages and for different IdPs. We provide an App Access Proxy which decouples authZ and authN from your apps and APIs. We integrate Auth0, Okta, Azure AD for you and you just need to put our lightweight container proxy in front of your apps. If you don't have too many apps, it's free for use! Checkout more details here. https://datawiza.com

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

#206
post #189

Earlier quoted context omitted.

I had to do this on a recent project because Corporate IT departments sometimes flag anything that has a create account / login prompt with a password field. Once you get on their shitlist it can take months of fighting the red tape machine to get off of it again. So we bypassed that with passwordless login using email. Unrelated, but we also discovered that one corporate had some kind of batshit crazy network where…

Not that uncommon for large companies to bring their IP space in house to multihome and load-balance traffic across multiple providers. If they are routing traffic back to random data centers for centralized filtering, it makes sense how it could be coming from different regions. I'm more interested in what made your application sensitive to this. The duplicate packets does sound bizarre. Maybe a mirroring issue or f…

The changing ips were ok, it just made diagnosing the issue difficult in the logs. The duplicate requests (not at the packet level as TCP ignores duplicate packets) were the root cause of the issue.

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

#207
post #169

This speaks to me. I will patiently wait for SSO capability. With that being said, if anyone has built scalable SSO flows specifically Azure AD, and want to help us implement it - please get in touch.

We can help. Check it out here. https://datawiza.com. Also we are a Microsoft partner.

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

#208
post #188

For my little web app I just went with passwordless logins and did the "magic token sent to the inbox" thing. I no longer have to deal with passwords at all; a security breach is (mostly) useless in terms of mining creds; and all of the password handling workflows are now the email provider's problem. If someone loses access to an email account then I can use manual processes to verify the person and change the email…

I have tried something similar, although I am encountering issues with people having to wait 10+ minutes for their codes at times, yet sometimes it arrives immediately, which is frustrating when it comes to login. I haven't spent any time debugging in depth yet, apart from looking at the email headers and seeing that it takes over 5 mins for the email to get from SES to Gmail. Not sure why!

MXroute has a blogpost where he digs into this a bit. IIRC it actually gets accepted by Google immediately - but then spends 5mins in the ether inside Google before it hits a Gmail inbox. No way to tell what the delay is coming from, other than it appears to be out of our hands.

Edit: https://mxroute.com/delayed-delivery-to-gmail/

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

#209
post #188

For my little web app I just went with passwordless logins and did the "magic token sent to the inbox" thing. I no longer have to deal with passwords at all; a security breach is (mostly) useless in terms of mining creds; and all of the password handling workflows are now the email provider's problem. If someone loses access to an email account then I can use manual processes to verify the person and change the email…

I know I'm the exception but as a privacy oriented user I hate this. There are services that try to track me across the net when I'm logged in so I never log into them except in a private window. This works great when my browser has the name/password saved because I go to the site and its one click to login. It sucks though when it's email login. I now have to click "login", wait 10 second to 3 minutes for the email to arrive. Copy the link from the email to the private window. It basically means I avoid using that site most of the time. (Medium)
Post reply on HN