I should have started out by saying this looks really neat, which is why I downloaded it to try out on my phone! :) thanks for sharing! Sorry my only comment was a criticism/question.

Looking forward to trying it out on the computer instead!

It's not super hard in principle. I work with car manufacturers, we have to let the user login via their OEM account. In theory they say it's all compliant, but then many parts don't work and take ages for them to get fixed.

What you described should really not happen though, I thought Google forbid this already

This is called OAuth 2.0 and is trivial to implement with something like Okta.

Or we could not encourage depending on a constantly-breached centralized “security” authority. https://hn.algolia.com/?q=okta

This feels a bit like NIH syndrome to me. Maintaining your own authentication solution is not trivial, especially for small/one-person operation.

Edit: Re-reading, I guess this is specifically targeted at Okta, who have had their share of problems.

Yeah it is known that one should use a library for authentication. It's also observed that they keep getting breached. The two sentiments "Best practice is use Okta" and "Okta keeps falling over" are inconsistent but the industry doesn't seem to have worked out what to do about this yet.

> Yeah it is known that one should use a library for authentication.

A library, yes, but a library is not a service. If you self host your auth stack with trusted primitives from a well known crypto library, you're much better off than if you outsource the very security of your platform to a company that has time and time again shown that they are incapable of preserving the security of even their own employee's personal info, much less anyone else's. At this point it would be arguably criminally negligent to rely on them to protect any sort of private information for your customers.

If you self host, someone needs to personally pick you as a target and find a flaw you made to get into your system. With Okta, they in all likelihood already have access. I know this industry loves learned helplessness (especially when the solution is “you don’t have to know the fundamentals, just pay us every month and we’ll do them for you!”), but come on.

Is there really a better alternative? Using a centralized service is certainly more secure than every company implementing a bespoke auth system.

Also, there are super strong incentives to hack Okta, so naturally more people will try to hack Okta.

I always thought it would be cool to have everybody carry around a private key on some device, and that key signs all data to prove authenticity. Instead of creating user accounts on a forum, posts would be signed with a key and a hash would be appended to the username, so you know that this John Smith is the same one as the last post because he has the same hash appended. Kind of like what 4chan does with tripcodes

You'd instantly have to deal with people losing their keys, people damaging their keys, people's pets eating, digesting and defecating the keys, fire/floodwater/storms/earthquakes/other natural or man-made disasters destroying the keys, keys getting damaged by ESD or cosmic radiation, people stealing other people's keys for extortion or abuse... spread any technology over millions of people and you will experience all sorts of failure modes that you haven't even thought of.

All of these failure modes need some sort of "customer support" to work out, otherwise they'll not be used by users at all or they'll lead to shitstorms when people are locked out of their identity. And if the customer support makes errors or gets bribed, you'll get shitstormed too.

And allowing people to back-up their keys isn't an option either because that defeats the purpose of why you have an HSM anyway.

Security is hard, PKI is even harder.

I also personally believe identity online should be transient. Getting locked out of your identity should be as simply fixed as creating a new identity

> is certainly more secure than every company implementing a bespoke auth system.

That's certainly what they want you to think. But hooking into a system where every support engineer's full contact info (and every other employee besides) is already leaked to hackers to do all the social engineering/extortion they might want, is faaaaarrrrr more insecure than using some trusted crypto primitives to validate a password, or send an email.

If you can get away with it, just email magic links or bog standard username/password that everyone knows and every credential manager can trivially incorporate with. If you need SSO (for your big enterprise contract to go through), the story is a bit different because in all likelihood every other thing they interface with is already using Okta, but that doesn't mean you must use them too.

> Also, there are super strong incentives to hack Okta, so naturally more people will try to hack Okta.

Why would you purposefully pick such a massive target? Especially one that is currently compromised, and can't even be trusted to protect themselves? Just last month hackers got all the personal information of all Okta employees.

There are enough solid systems (such as keycloak) that implement standard mechanisms (such as OAuth2 or OIDC) that using a service that continually has issues (as noted by the gp) should be justified, not assumed (having an SSO system should not be conflated with a specific provider).

Rolling your own is rolling the dice, but using something like Okta is guranteed (to leak).

Why would you need Okta for a simple Google sign in? A simple traditional Google OAuth flow should work just fine.