[HN Gopher] Okta to Acquire Auth0 for $6.5B
___________________________________________________________________
Okta to Acquire Auth0 for $6.5B
Author : lpage
Score : 609 points
Date : 2021-03-03 21:04 UTC (1 days ago)
(HTM) web link (www.cnbc.com)
(TXT) w3m dump (www.cnbc.com)
| logronoide wrote:
| I left Auth0 on Tuesday and one day later the company triple its
| value. Never thought I would be such a drag...
| sytringy05 wrote:
| Wow, I wonder if this will create some space for a new
| competitor? I mean apart from these 2, who else are a serious
| option for rock solid SaaS IdP?
| marton78 wrote:
| ory.sh
| erulabs wrote:
| I recommend SuperTokens https://supertokens.io/
| advaitruia wrote:
| Thanks for the Shoutout!
| daenney wrote:
| > All other providers require an OAuth implementation even if
| you do not need SSO because of the way they've architected
| their solution. With SuperTokens, we've decoupled the
| functionality for different use cases, making it possible to
| only worry about the features you need.
|
| Eh? You're either doing Oauth or you're not? What have they
| decoupled?
| rishabhpoddar wrote:
| For example, if you require email / password auth without
| SSO, then we do not use open ID connect or any of the oauth
| flows - because those are not needed in a simple setup.
| SahAssar wrote:
| Not having any 2FA makes it a non-starter for a lot of
| people.
| advaitruia wrote:
| We're working on it! Passwordless will be our next release
| in a few weeks and then 2FA comes next
| cpitman wrote:
| For Enterprise SSO, the market that Okta focuses on, Azure AD
| is by far the biggest player. They get their foot in the door
| at companies with Office365, which then makes it a really easy
| move for companies to consolidate all SSO there. Other
| responses are commenting on features, but AAD is _everywhere_.
|
| The only other hosted solution (other than Okta and AAD) I have
| ever seen at my clients is Ping. In comparison, all the other
| players are nowhere as nearly established.
| grinich wrote:
| Come try WorkOS! http://workos.com/
| brokenwren wrote:
| Come on over to the FusionAuth! The water is great! -
| https://fusionauth.io
| ignoramous wrote:
| > _...who else are a serious option for rock solid SaaS IdP?_
|
| Google Cloud (Firebase Auth), AWS (Cognito), and Azure (Active
| Directory) are as rock-solid as they come.
|
| FusionAuth.io, userbase.com, and clerk.dev come to mind as
| well.
| technics256 wrote:
| Anyone who's used cognito knows it's a joke compared to the
| others.
| irgeek wrote:
| Cognito is a joke. It's full of bugs, the hosted UI doesn't
| support half the features and -- based on the change velocity
| I've seen over the last three years --- it is desperately
| under-resourced by AWS. The new releases always seem to be
| small changes (like adding a new OAuth provider) but never
| fixes for the major bugs.
| tanseydavid wrote:
| Azure Active Directory leaves much to be desired.
|
| If it was not a MS product it would struggle to attract a
| market.
| pionar wrote:
| How so? I'd argue they're far ahead of the competition in
| features.
| brokenwren wrote:
| Except for all the basics like RBAC with multiple roles,
| JWT modification, simple MFA, etc.
| motives wrote:
| AAD implements SAML, OIDC, LDAP, Kerberos, FIDO2 and more.
| Even if it was not a Microsoft product, it would have
| better non-proprietary interoperability than most other SSO
| platforms.
| mooreds wrote:
| There are lots of competitors, all at varying levels of
| sophistication and targeting a wide variety of markets. Lots of
| them mentioned in sibling threads, but I work at another one
| that is really dev focused:
|
| https://fusionauth.io/
| giantandroids wrote:
| https://www.keycloak.org/
| crazygringo wrote:
| > _Okta, whose cloud software allows office workers to access all
| of their apps through a secure online service, said on Wednesday
| that it's spending $6.5 billion to acquire rival Auth0. Okta's
| shares plunged about 13% in extended trading after the
| announcement._
|
| Huh? Generally speaking, companies acquire other companies to
| become _more_ valuable, not for their shares to go _down_. And
| even more so when the acquired company is a _competitor_.
|
| Why do investors think this is such a backwards idea, and why did
| the board approve an acquisition that investors appear to be
| rejecting?
|
| This is extremely unusual and the article provides zero
| explanation whatsoever.
| Clewza313 wrote:
| The default explanation for the share price going down is that
| the market thinks they're paying too much. And let's face it,
| $6.5B is pretty toothy. (Remember when FB paid $1B for
| Instagram and everybody lost their minds?)
|
| But apparently Okta is also going to issue 21% new shares,
| diluting existing shareholders, so going down only 12% means
| they're actually kinda-sorta up 9%.
| AznHisoka wrote:
| The stock literally dropped a few seconds after the press
| release was out. This wasn't investors reading the details and
| thinking "Oh, this acquisition is a disaster, let's sell our
| shares". It was algo funds that saw something they didn't like,
| and decided to trigger a bunch of selling.
|
| If investors really like the acquisition, they will probably
| buy more shares in the days/weeks ahead.
| fnord123 wrote:
| The shares of the purchasing company always go down as the free
| cash available is being spent - or debt being taken on - on
| something at a premium.
|
| More explanation here:
|
| https://www.investopedia.com/ask/answers/203.asp
| shubik22 wrote:
| I think it's actually quite common for the acquirer's share
| price to decrease following the announcement of an acquisition.
| (See e.g. this HBR article from 1999:
| https://hbr.org/1999/07/are-you-paying-too-much-for-that-
| acq....)
|
| One simplified reason for why this occurs is that the
| management of a company is who decides whether to make an
| acquisition. That management might think it's in their interest
| (prestige, compensation, etc.) to lead a larger, more important
| company. One way they can do that is by acquiring a competitor,
| and they might even be willing to overpay to accomplish that
| goal. The board of the company, often appointed by management,
| doesn't provide true oversight of the management's decisions.
|
| In other words, the incentives of management are misaligned
| with the incentives of investors.
|
| Management's response to this theory might be that the market
| (investors) doesn't understand their business, and isn't
| properly valuing the acquisition.
|
| I'm more sympathetic to the first view, but I believe there's
| research supporting both views.
| throwbacktictac wrote:
| Wow, I would not have guessed that Auth0 was that valuable. Part
| of the premium must be to keep it out of the hands of a worthy
| competitor.
| Azeralthefallen wrote:
| I hate this. We moved from Okta a few years ago after we were
| basically received almost no actual real support for a bunch of
| issues, even though we were paying a premium cost. Nobody cares
| about issues on their Github, the kicker was a when we received a
| support response as suddenly something was no longer working
| after an update, we got help in the form of "We have no plans to
| address this anytime soon." when asking for an ETA.
|
| We ended up switching to Auth0, after we had a few calls with
| them. We shaved a decent amount off our costs with Auth0's
| Enterprise plan, and their webtask based rules worked. While the
| migration sucked for a bit, in the end we were much happier.
| nijave wrote:
| Sounds right. We use Okta for multiple AWS accounts and they
| "ran a bad migration" that deleted half our permissions and
| took a month to resolve. On top of that, nothing appeared in
| the audit logs.
|
| To make matters worse, they have 3 APIs. Two are internal with
| 1 html and 1 json-based. The external one is the least feature
| rich and is missing configuration items that make IaC a
| challenge (you get about 80% configured then have to make
| changes in the gui)
| throwbacktictac wrote:
| I've never dealt with Okta support but my support issue with
| Auth0 was top notch.
|
| However, their 'Rules' system for hooking into the Auth request
| is abstracted at the Auth0 account level rather than the
| individual app level. That makes it too easy to accidentally
| screw up all of the apps on an account.
| kall wrote:
| I like the product but the extension points confuse me.
| Rules, Hooks and Actions are all more or less the same thing?
| I never know which one I want. What's difference between a
| flow and a pipeline? You definitely can't guess from the
| terms.
| mc32 wrote:
| I've heard good things about Onelogin. I think Duo also seems
| to be another option.
| theptip wrote:
| Can second this, Okta requires you to "contact support" to turn
| on basic features like email customization, and even though I'm
| a paying customer, I was given a multi-week estimate (after
| waiting a week or two) for how long it would take to enable
| this feature.
|
| It's a flag in the web UI in Auth0.
|
| This did not fill me with confidence.
| davewritescode wrote:
| I will 3rd this, this is my major issue with Okta in general.
| Other than that it's been pretty good for us.
| hangonhn wrote:
| Yeah current Okta customer and same experience as you. I was
| thinking of maybe going to Auth0 but well at least this news
| came out before we put any serious work into planning.
|
| _sigh_
|
| Auth0 at least has much better docs and libraries. It feels
| like Auth0 at least cared more.
| marc__1 wrote:
| More information on the ppt
|
| Auth0
|
| 200M ARR
|
| 50% Growth
|
| 120%+ Net Retention Rate
|
| https://investor.okta.com/static-files/83f1811e-2f92-4c08-a1...
|
| What a great acquisition. Congrats to both teams!
| capableweb wrote:
| > What a great acquisition. Congrats to both teams!
|
| Great acquisition for those two, what about customers who
| always seem to lose when companies get acquired? The market now
| has less competition, people who were using Auth0 is eventually
| gonna have to modify their infrastructure because of this and
| things will become more unstable.
| marc__1 wrote:
| Bezos apparently said one that "Your margin is my
| opportunity".
|
| If this merger increases future profitability of new Okta,
| then you can argue there is a newer genuine market
| opportunity in authentication.
|
| The VC-backed industry is all about creating new
| opportunities (and by definition disrupting someone else's
| business), and recirculating investment money, improving our
| economy
| cat199 wrote:
| > market opportunity in authentication.
|
| As in any publicly traded company - there are 2 markets at
| play - capital markets, and the market for the actual
| products
|
| > The VC-backed industry is all about creating new
| opportunities (and by definition disrupting someone else's
| business), and recirculating investment money, improving
| our economy
|
| 2 words I don't see in this sentence are 'product' and
| 'customer'
| ramraj07 wrote:
| Honestly as auth0 users we were mulling moving over to okta
| anyway. Auth0s offering has always been slightly rough around
| the edges and we end up slightly suboptimal implementations
| because of that.
| scrollaway wrote:
| If that were the case, Okta would not have acquired Auth0.
| techrat wrote:
| Acquisitions don't happen exclusively because a company
| is buying out someone who is better than them.
|
| Sometimes they happen so a company can buy out someone so
| they won't have the chance to become better than them and
| a serious competitor.
| capableweb wrote:
| And for those in the back that don't know, using that as
| a reason for an acquisition is illegal and considered
| anti-competitive practice, hence you'll never hear a
| company publicly state that reason.
| [deleted]
| cat199 wrote:
| but you will hear:
|
| Sometimes they happen so a company can create synergies
| and improve the scope of their product offerings
| mschuster91 wrote:
| Taking over a competitor is always a good idea, simply to
| reduce the amount of players you compete with. This is
| why Facebook gobbled up Instagram and Whatsapp.
| Clewza313 wrote:
| Really? $6.5B is over 32x their current run rate, and that's
| projected _revenue_ , not actual profit.
| ZephyrBlu wrote:
| Those numbers are pretty insane though, especially the Net
| Retention.
| staysaasy wrote:
| I'm with you that 32x feels insane, but these are crazy times
| and Okta presumably had to pay a premium to take Auth0 off
| the market. With those stats and a compelling story
| (developer tools) they were probably expecting a great IPO in
| this market. Assuming a 20% premium to take them off the
| market, 32x doesn't seem that crazy with many public
| companies trading at 25x or more.
|
| But yeah... it does feel a little bit like that moment where
| you go over the top of a roller coaster...
| f430 wrote:
| we are in a credit bubble after all
| mooreds wrote:
| Those are some killer numbers!
| dang wrote:
| We changed the URL from https://www.okta.com/press-room/press-
| releases/okta-signs-ag... to a third-party article. Usually
| though not always, corporate press releases are tepid devices
| whose purpose is as much _not_ to say things as to say them, or
| at least not say them outright. So generally we prefer the best
| third-party article on a topic.
|
| https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...
|
| (Cases like this are an exception to the 'original source' rule
| in https://news.ycombinator.com/newsguidelines.html.)
| Heririe wrote:
| Good
| ffo wrote:
| We are building a cloud-native IAM over here
| https://github.com/caos/zitadel
|
| It is written in Go and built around event sourcing for a great
| audit trail. We already support OIDC, Passwordless, RBAC and
| working on more features each day.
|
| For those who want to run it on-prem we have a kubernetes
| operator ready in the next few weeks who also manages the
| database (cockroach).
|
| We run our own service here https://zitadel.ch with a free tier
| as well
|
| Feel free to engage with us on GitHub discussions.
| estsauver wrote:
| Congratulations to the Auth0 team! We're happy customers, and we
| hope things don't radically change as they merge into Okta.
| [deleted]
| astuyvenberg wrote:
| Congrats to the Auth0 team! Their product solves a really tricky,
| undifferentiated problem that I'm glad I don't have to solve
| anymore.
| ericlewis wrote:
| I've used this a lot and it is stupidly expensive typically -
| hopefully this acquisition makes it more pervasive because they
| do a seriously great job at what they do!
| supermatt wrote:
| Urghh.. and to think I got rejected the season before Auth0 got
| accepted for exactly the same idea. Anyone have any tips on
| actually getting noticed at YC? Didnt even get past video pitch
| :/
| kall wrote:
| If anyone is looking for an alternative on the opposite end of
| the scale from enterprise, to add login to an MVP in a few days,
| I have been collecting newer services that go beyond passwords
| and Sign in with Google:
|
| Feather: https://feather.id
|
| Magic: https://magic.link
|
| Cotter: https://www.cotter.app
| SavantIdiot wrote:
| stormpath > auth0 > okta > ??
|
| Wonder who buys them next. This will be the third time I've
| updated my deployments.
| unclekev wrote:
| > Wonder who buys them next
|
| Cisco or Salesforce
| toomuchtodo wrote:
| Salesforce?
| basch wrote:
| Would be a smart move for Adobe as well.
| bonsai80 wrote:
| Random safe bet seems to put to put Salesforce on the right
| right side of such a diagram, regardless of what the left side
| companies do. :)
| cphoover wrote:
| A lot of people are saying they hate this, I understand why.. But
| perhaps the culture at Auth0 can infiltrate Okta instead of the
| other way around
| nojvek wrote:
| As just another average Joe/Jane, what can I do to influence
| anti-trust department that this merger is a bad idea for
| competition? It really does surprise me how many mergers are done
| purely for market capture reasons. The US Tech industry has a few
| bully behemoths who keep on getting bigger and a ton of smaller
| players.
| Elesant wrote:
| If anyone's looking for an Auth0 alternative, definitely check
| out: https://magic.link/ - easy plug-n-play auth, friendly-
| pricing for startups
|
| CEO here, ask me any questions!
| TruthWillHurt wrote:
| Farewell Auth0.. you had potential, shame you joined such a shady
| operation like Okta..
| ar_lan wrote:
| I was wondering when this was going to happen.
| mooreds wrote:
| Really? I am in this space and didn't see this at all. Auth0
| (and other competitors) seemed to be growing quickly. I don't
| know why they wanted to sell; must be a really good offer +
| some synergies.
| chromatin wrote:
| Hm, I now cannot find the other thread which had 40 some comments
| (but also linked to the corporate press release).
| dang wrote:
| Merge in progress. Please stand by!
|
| Edit: Merge completed. Please resume reading!
| joemaller1 wrote:
| Cloned the jwt.io site, just in case.
| dec0dedab0de wrote:
| Does anyone else think its a horrible idea to outsource your
| companies authentication?
|
| Where I work we are migrating to Okta, and it blows my mind that
| anyone thinks it is a good idea.
| oftenwrong wrote:
| It's no different than any other "build vs buy" decision. If
| you think you can provide your core offering AND implement
| complex authentication requirements half as well as a dedicated
| authentication-SaaS company, good luck. Businesses "buy"
| because it's the low-risk path.
| sojournerc wrote:
| I'd actually say the opposite.
|
| Any small start-up is not likely to have the expertise to
| implement auth in a 100% spec compliant, HIPAA certified, SSO
| compatible manner.
|
| It's not a de-facto BAD-THING to outsource skills outside of
| the niche of a business, and is likely more secure and thought-
| out than what would be created otherwise.
| coderintherye wrote:
| Im sure you could find people that think it is a bad idea, but
| most people including myself find it to be a good idea.
|
| What do you see to be horrible about it exactly?
| mooreds wrote:
| There was a big discussion on this a few weeks ago:
| https://news.ycombinator.com/item?id=25848349
|
| (Disclosure, the post that sparked the discussion is on my
| company's blog.)
| lpage wrote:
| Full details are in the investor release [1]
|
| [1] https://investor.okta.com/static-
| files/83f1811e-2f92-4c08-a1...
| fumar wrote:
| Okta stock dropped 12% in after hours. I see the acquisition as a
| positive business decision.
| missedthecue wrote:
| Dropped because OKTA will issue an additional 21% of their
| outstanding stock to make the purchase, diluting existing
| shareholders
| basch wrote:
| But shareholders own an entire nother company now.
| djrogers wrote:
| The stock dropping only 12% after a 21% dilution reflects that
| 'the street' sees this as a net positive as well.
| conro1108 wrote:
| Wouldn't that just mean that the delta between the dilution
| and the stock drop was 'the street's take on the "real"
| valuation of auth0?
| paranoidrobot wrote:
| Really not a fan of this.
|
| Okta as a business are a pain to deal with, and unless you meet
| their minimum spend requirements (which are not told to you up-
| front) you're screwed.
|
| I've rolled out a ton of commercial products where we started
| with 1-2 users or a few units of compute, and on the basic
| little/no support options.
|
| When those products succeed, and we can demonstrate that not only
| does it meet our needs on paper, but it actually works, and
| whatever flaws that exist are not big enough to stop us wanting
| to use it more.
|
| AWS, Atlassian's Jira and Confluence, Sendgrid, Mailchip, Duo,
| and a bunch of others all started being used in orgs where this
| kind of thing is super low friction and easy to spin up, we plug
| in a credit card to get us off the ground.
|
| Okta? Well they'll tell you the pricing up-front, that's great -
| what they don't tell you is that after the trial period, you
| can't just give them a credit card, no you need to go through the
| sales process. It's not until you're talking to their salesperson
| that you find out you can't just start with a few licenses, no,
| you need to meet their minimum spend figure per month.
|
| Well, that idea was dead.
| mattchamb wrote:
| I've seen the "we cant take credit cards and just start
| charging" fight play out on the other end. The reason was that
| the sales teams objected to their commissions being bypassed,
| so everything had to funnel through the sales pipeline.
| quickthrower2 wrote:
| Funny so they'd rather lose business than sales commissions.
| andy_ppp wrote:
| I might be mad but auth0 really for $6.5bn, seems like a pretty
| simple problem solved in a quite mediocre way. I mean the common
| use case of an app+api+website login seems excruciatingly
| difficult to setup, surely something that did this by default and
| didn't need configuration unless breaking out of this model would
| be preferable to the weirdness I've had on the 3/4 occasions I've
| set it up now.
| [deleted]
| packetlost wrote:
| Oh no
| grinich wrote:
| If anyone's looking for an Auth0 alternative, come check out
| WorkOS!
|
| It's like Stripe for enterprise features, including SSO/SAML,
| Directory/SCIM, and more.
|
| https://workos.com/docs
|
| (I'm the founder.)
|
| Edit: Here's our launch last year:
| https://news.ycombinator.com/item?id=22607402
| btown wrote:
| This really looks amazing! I saw your post describing your
| product in relation to Auth0/Okta at
| https://news.ycombinator.com/item?id=26070302 and it makes a
| ton of sense. Many (most?) enterprise-facing startups don't
| start out that way, and it's painful in practice (and in
| principle!) to be power-sold to "lift" your existing users into
| a solution like Auth0, just to accept SAML logins for new
| users. And pricing per connection is infinitely more
| justifiable than pricing per user, especially in that context,
| especially with today's acquisition removing any downwards
| price pressure on that per-user pricing!!!
|
| I might reach out to you with some questions about our use
| cases - we're in early conversations with an enterprise client
| who _uses_ Auth0 for their user management, and ideally we 'd
| be able to use their Auth0 as an IDP for SSO into our existing
| Django application. Would also love to pick your brain on
| potential solutions for B2B2C use cases - your Admin Portal
| concept reminds me very much of a page I've written far too
| often in the past :) Feel free to reach me as well at
| btown.hn@gmail.com.
| grinich wrote:
| Yep, we can definitely support Auth0 as an IdP. It's a less
| common set up (versus IdPs like Okta or Azure AD) but still
| something we support.
|
| Feel free to send me a note. (Or anyone reading this too!)
| I'm mg@workos.com
| duncans wrote:
| Had a quick look at your docs for integrating with Azure AD
| SAML https://workos.com/docs/integrations/azure-ad-saml and
| wondered why you don't make use of SAML metadata URLs that
| contain all this configuration? For example the signing
| certificates, ACS, Reply/ACS URL, EntityIDs are all in the
| metadata xml docs, so you could boil it down to:
|
| * Here's the SP metadata URL - upload it into Azure dashboard
| here ...
|
| * Grab the "App Federation metadata URL" from the Azure
| dashboard and paste it into WorkOS here ... (where your app can
| parse the XML and grab certs, URLs etc)
|
| And you're done.
| grinich wrote:
| We're planning to push all configuration to metadata
| endpoints for providers who support it. There are additional
| benefits for refreshing SAML certificates (usually every 5
| years) and dynamically adapting to other attributes changing.
|
| This will get added to our Admin Portal, which is a pre-built
| experience for IT admins to configure SSO connections:
| https://workos.com/docs/admin-portal/guide/introduction
|
| Unfortunately the metadata URL configuration path isn't
| universally supported. I'm hoping FastFed solves this, but
| all that is still in working group / pre-RFC.
| https://openid.net/wg/fastfed/
| jcmfernandes wrote:
| We are happy WorkOS customers at hopin.com :) their SDKs make
| integration dead easy and their team is super responsive.
| Thanks @grinich and all the WorkOS team!
| ryanjodonnell wrote:
| We use WorkOS at Cleary for SSO with microsoft exchange - works
| great and the team is super responsive and friendly. Thanks
| @grinich!
| cellar_door wrote:
| Stock is getting hammered in after hours on top of -6.89% today
| randompi wrote:
| Oh man. Was planning on using Auth0. Never heard of Okta, but
| reading the comments in here has confirmed my suspicion of the
| company's core value. Now I'm having doubts.
| bashmohandes wrote:
| Okta is an awesome company, there will always be doubters, do
| your own research, and don't trust anonymous chats on some
| internet forums, including myself.
| macintux wrote:
| Effectively a dup: https://news.ycombinator.com/item?id=26334659
| dang wrote:
| That one was posted later, so I think it will be fairest to
| merge hither.
|
| (Item IDs are the definitive way to check that btw.)
| didip wrote:
| How do both of them make money?
| cheald wrote:
| If you want to own your identity management, consider Keycloak.
| It's mature, battle-tested, and works like a champ.
| advaitruia wrote:
| Cheald, SuperTokens isnt as mature as Keycloak but we make up
| for it in other ways (ease of implementation, frontend UI,
| hosted offering, docs and support). Would appreciate your
| consideration!
| andrew_ wrote:
| I hope this gives rise to another, smaller viable party outside
| of Amazon, Google, and Microsoft. Perhaps I'm jaded, perhaps
| hopelessly biased - but I can only see this as a net negative.
|
| Okta's open source packages receive a pitiful amount of attention
| (for example: https://github.com/okta/okta-oidc-
| js/issues?q=is%3Aissue+is%...) with forks almost becoming a
| requirement. Auth0 by contrast has been "on the ball" for a long
| time with their offerings. Okta's interfaces have been disjointed
| and inconsistent, confusing to users on a scale only surpassed by
| Jira, while Auth0's have always been pleasant to use from a user
| and developer perspective.
|
| From a personnel perspective, the two companies couldn't be more
| different, with Auth0 embracing a remote-first-class culture with
| creative interview processes, and Okta (pre-covid) being very
| much the opposite. I interviewed with both, and the process at
| Auth0 had me walk away with respect, while contrasted with Okta
| that left me reminded that tech hiring is broken.
|
| I'll hold my breath for a short time that Auth0 is allowed to
| operate independently. Sadly I feel it'll be inevitable that
| they're eventually swallowed up by the mothership.
| ernsheong wrote:
| There's Ping Identity [1] and Firebase Auth [2], though
| Firebase is probably not as feature rich as Auth0
|
| [1] https://www.pingidentity.com/ [2]
| https://firebase.google.com/docs/auth
| aussieguy1234 wrote:
| I did an integration with AWS Cognitio. It can only act as an
| oauth client, not a server.
|
| So it can only let people log in with Google etc, not log in
| with <your app> on other apps
| Riptide34 wrote:
| What? You can use Cognito User Pools to sign-up and manage
| user accounts in-house. That's the core of any identity
| solution. You can hook up Google, Facebook, etc. as identity
| providers if you want to give your users a third-party sign-
| in option.
|
| Maybe I'm misunderstanding your use case, so correct me if I
| got something wrong.
| vwpolo3 wrote:
| There are already true open source alternatives on the horizon
| such as https://github.com/ory
|
| It is about time for a new generation of identity systems in my
| opinion. This acquisition shows the risk of centralized, vendor
| locked-in services.
| ForHackernews wrote:
| https://www.keycloak.org/ is another open source option.
|
| Compared to other choices, it's more mature and well-vetted
| because it forms the upstream for RedHat's SSO offering.
|
| On the other hand, it's a big monolithic Java app, but they
| are making some moves to be more CNF-friendly:
| https://www.keycloak.org/2020/12/first-keycloak-x-
| release.ad...
| skeeter2020 wrote:
| If you are going to use keycloak it's worth making sure
| their mental model matches your own. Specifically we had
| issues with our model of multi-tennacy, each in their own
| realm vs. the keycloak idea of multiple tennants in a
| single realm. It caused some large performance and
| management issues.
| EtienneK wrote:
| Yeah Keycloak is great. I've tried using other open source
| alternatives, but none are as full-featured and mature as
| Keycloak.
| eropple wrote:
| Ory is really interesting but not, IMO, quite there yet.
| There are a bunch of Kratos features that aren't there but,
| once they are, I think it's a really compelling option.
| mamcx wrote:
| I try to like it but it have a HARD stand against multi-
| tenant deployment.
|
| This is a major weak point of many solution, in special how
| automate it.
| manigandham wrote:
| Also https://identityserver.io/
| drakonka wrote:
| We used ORY fosite to write our auth service, and I have so
| far really enjoyed working with the lib. Feels like they
| aren't as focused on external users of the fosite lib though
| so much as their hydra solution which consumes it. The
| overall ORY ecosystem seems nice though, though I have not
| delved into it in detail past fosite.
| msaidentity wrote:
| If you're looking for next generation of identity solutions?
| https://magic.link is what everyone would need, provides
| decentralised identity, fair pricing and no vendor lock-in.
|
| I love their startup pricing.
| atlgator wrote:
| I wish I knew python. I would kill for the backend
| developer job they have open. I love IAM.
| sontek wrote:
| I _hate_ this magic link flow. Its a major pain in my ass
| when I already have a password manager that knows how to
| login. Now I have to leave my browser and go to my e-mail
| client that will open a _new tab_ even though I already
| have one open.
| oftenwrong wrote:
| Auth0's GitHub account and documentation basically sold me when
| I was comparing auth services.
| tudorconstantin wrote:
| If you have enterprise level needs for a full customer identity
| solution, especially if your company activates in Europe, let
| me suggest you https://www.iwelcome.com/ (disclosure: I work
| here as an engineer): long history (founded in 2011), very
| reputable companies and institutions as long term clients,
| superb customer support, 0 security breaches, and the delegated
| user management solution we have is among the best in the
| industry, if not the best - I personally haven't seen anything
| like this, even though I tried Cognito and Auth0.
| jrockway wrote:
| I was thinking very seriously about starting this company.
| There were some details I could never work out, and then Covid
| hit, so I didn't pursue it.
|
| My thoughts are:
|
| 1) One login per day per person is the maximum number of times
| I would ever consider asking for authentication. This is where
| OAuth fails; you visit an app that wants you to authenticate,
| but you don't get automatically logged in. You have to click at
| least twice. Huge drag and I hate it to death. When I worked at
| Google, we had BeyondCorp and I was asked for a password and
| security key touch once a day and could then browse internal
| apps freely. I would not accept anything less. (Okta and Auth0
| fail here.)
|
| But, this requires infrastructure, like trusting client devices
| and their screen locks. Writing software to secure some random
| bring-your-own-laptop is a full-on company in and of itself,
| and if that fails, your whole authentication system fails.
| (Malware starts impersonating the human.) Google's corporate
| engineering got this right, but I don't have that
| knowledge/experience to do that myself.
|
| 2) I really like the "identity aware proxy" design. There is an
| internal network, your app servers run there, and the proxy
| bridges that to the Internet and handles all the authentication
| details. The proxy signs a token that says who accessed it, and
| the app doesn't need to care. The problem here is that no apps
| support this. Every open-source web application bundles 10,000
| lines of code for their own IAM system, and everyone seems
| totally fine with this. There is no standard, really, for
| identity aware proxies, and therefore no way for an app to
| recognize a standard token. (And, apps also need to do IAM
| management beyond just knowing who the logged-in user is, so
| you need a protocol to talk to the identity provider.) Yes,
| OIDC tries to fix some of these things, but it really isn't ...
| good. It optimizes for the problem of letting you log in to
| StealMyEmail.com with your Google account, without compromising
| your entire Google account. Not what people need for their
| internal applications.
|
| Anyway, I bring it up because people clearly don't like this
| idea. They can't run an "internal network" securely, because
| you see the same flaws with this architecture again and again
| -- chat service's link unfurler takes a malformed link and
| makes a GET request to an internal application and leaks data;
| someone's jumpbox gets compromised and their network gets
| completely owned; "SSL added and removed here :-)"; etc. Very
| few people have successfully set up internal mTLS, which you
| really need for the proxy model to work. So instead, they just
| treat each app as its own island with a set of users, and
| identity provider, and session tokens, etc. Okta and Auth0
| handle this case really well (well, they charge you a lot of
| money to pretend to sync the users), and that's why they're
| successful. But the user experience sucks, and the application
| developer experience sucks, and the application operator
| experience sucks. Hey, everyone's happy! Give me 6.5 billion
| dollars!
|
| 3) Every identity provider needs some answer to the SSH
| problem. People have been trying to do this for more than 30
| years and it continues to suck. I think it's unsolvable. But
| thinking it's unsolvable means you don't get any customers, so
| that's a problem for me ;)
|
| 4) People are very interested in add-ons that are required by
| standard compliance rules. To be in certain businesses, you
| have to have a "web application firewall", which is basically
| something that greps the incoming request for "DROP TABLE
| users" and returns an error if that's in there. Denylisting
| will never work, but maintaining that denylist is yet another
| full-time company. You'll never catch up with the established
| players here, at least not as a 2 person startup.
|
| 5) The product I wanted to make was a centrally-managed IDP,
| with little proxies you could place wherever you needed one. At
| my last job, this is something we tried to buy from Duo, but
| their product was terrible. Our software engineering team had
| one Kubernetes cluster, with one connection to the Internet
| that was easy to proxy. (We used Envoy, and I wrote an SSO auth
| plugin, and everything was great for us.) Our network
| engineering team just had VMs everywhere, with an nginx that
| reached out to Duo for auth. It checked the security box, but
| you had to log into every web app twice -- once to log into
| Duo, once to log into the app itself. Awful.
|
| Anyway, I do like the model. It's easy enough to write a nginx
| plugin and Envoy sidecar and whatever else people want, and
| then have it connect over TLS to receive instructions from a
| central leader. The tough bit is keeping those proxies
| functional when the central server dies (maybe new users can't
| login when it's down, but people with session material should
| be able to keep using it). There are a few designs -- just push
| the session cookie to every proxy when someone logs in and have
| the proxy check sessions with a simple string comparison. Now
| you survive some types of downtime (good luck firing someone
| when the central server is down), but that lets a proxy
| administrator start impersonating other users by writing a
| malicious proxy, GDB-ing it, whatever. So that's no good.
| Another option is to use public key crypto so that the proxy
| operator can't mint valid tokens, but every time I think about
| it I feel like I have the design, then I write out the details
| and find that it doesn't work. (That happened just now, I
| thought I had it for sure, but I don't ;)
|
| All of these details were the killer for me. The business looks
| tough, but the technology isn't easy either. I did get mad
| enough to write something for myself
| (https://github.com/jrockway/jsso2), but that is not something
| I would ever consider selling -- it's just a very simple IDP
| and authenticating proxy. Perfect for blocking HN users from
| visiting https://alertmanager.jrock.us/, but still lets me look
| at it from my phone. (With FaceID and not a password, of
| course!)
|
| I don't know what the future here is. Companies like Tailscale
| have the right idea -- don't trust any endpoint, human or
| "server". But you have to bring your own IDP, and applications
| can't know which human they are talking to. (Or at least, there
| wasn't an API to map the Tailscale source IP address to the
| human username when I last looked.) And, the mesh doesn't work
| for people that are already happy with having an internal
| network. I run everything on Kubernetes, and I don't want to
| use some crazy CNI to make every Pod a member of the network...
| too much stuff can break for the 0.0001% of the time when I
| want to directly connect to a Pod.
|
| I guess what happened is that nobody ever decided how things
| should be done, so everyone does their own thing. That makes it
| a difficult market for a startup to enter, because you have to
| hope that your opinion is shared by enough people to have a
| customerbase to support you.
|
| TL;DR: Everything is awful and it makes me mad.
| TheRealDunkirk wrote:
| > One login per day per person is the maximum number of times
| I would ever consider asking for authentication.
|
| Yes. Pet peeve. I started a new web app, which was going to
| have to integrate with our internal SAML server. Managers in
| the meetings kept referring to it as our "single sign on"
| system. I finally heard the phrase one too many times, and
| stopped the discussion to clarify that a "single sign on"
| means you log into a system ONCE, and then it takes care of
| every other authentication. I pointed out that we ALL spend
| ALL day re-logging into everything, and that shut everyone up
| pretty fast.
|
| And, yes, I'm fully aware that this sort of thing is why I'm
| not popular with our IT department.
|
| Fun story. I started integrating my app with SAML, and took a
| couple of days to learn it. I asked for the key to their dev
| server for testing, and this led to a FOUR MONTH series of
| meetings and emails where they told me WILDLY inaccurate
| things, which I repeated back to make sure I understood what
| they were telling me, and they insisted these things were
| true. (Like, all I had to do was put something in my headers
| to "authenticate".) Around and around we went until some
| other manager on a call pointed out that what I repeated was
| WILDLY inaccurate, and I shouted, "I KNOW! THAT'S WHAT I'VE
| BEEN SAYING FOR FOUR MONTHS," which made my manager tell me
| to calm down, but which FINALLY got someone to point me to
| the right person, deep in the heart of India, who sent me
| exactly what I asked for at the start, and it worked the
| first time.
|
| So, no, I don't care that I'm not popular with this group.
| mooreds wrote:
| > Fun story.
|
| Ouch! That's some definition of "fun".
| cdcarter wrote:
| > There is no standard, really, for identity aware proxies,
| and therefore no way for an app to recognize a standard
| token.
|
| How crazy is using the HTTP REMOTE_USER header for this?
| weehoo wrote:
| Would you mind elaborating on what you mean by "the SSH
| problem"?
| kornesh wrote:
| I thought I was the only one to get offended every time I
| have to relogin lol. AWS is the absolute worst, logs me out
| every 5 minutes.
|
| I have been fascinated about google's identity aware proxy
| design. We have adopted something similar at much smaller
| scale with kubernetes and sidecars, I can attest we're
| absolutely more productive.
| krysp wrote:
| On the point about AWS, there are settings in your account
| to prevent that happening - whoever is managing it may have
| set the log out time a bit low.
| LilBytes wrote:
| Even then the max session is 12 hours which can be
| cumbersome, though we've made it work using an IdP into
| AWS SSO.
|
| 12 hours is typically enough but, for the days it isn't
| (i.e. something breaks and I'm working over time), it
| becomes tiresome.
| advaitruia wrote:
| Have you seen SuperTokens.io? Its open source authentication.
| Maybe not as mature as Amazon, Google and Okta but we'll get
| there!
| jonplackett wrote:
| We use Okta at work.
|
| I have to re-log-in to everything, virtually every time I use
| it. Okta seems to have no ability to remember who I am, or even
| that I've used this browser 10000 times before and don't need
| to be Two-Factored for the 10th time today.
| faichai wrote:
| I asked for a trial login for Okta a few years ago. They sent
| it to me, but it didn't work. Not great for an authentication
| company. Made a point to avoid them based on that experience.
| kenm47 wrote:
| Have you heard of https://fusionauth.io/ ? I'm not a user of
| the product, but I know some of the folks behind it. Might be
| time for them to shine here.
| robotdan wrote:
| Thanks for the mention. We already do see quite a few Auth0
| converts. I expect to gain a lot of new customers as a result
| of this merger in the coming months. No complaints here.
| hanikesn wrote:
| FusionAuth looks quite interesting. I'd like to see a
| comparison with AzureActiveDirectoy as well as in my last
| company we ended up sticking with it instead of migrating
| to auth0/octa/servicenow. Especially because Developer
| self-service works very well there. I couldn't find any
| details about this on your website.
| neom wrote:
| Hey Dan, curious: why it's so difficult to figure out who
| is behind the company from the website?
| brokenwren wrote:
| We are working on that. Our new website will include a
| ton of information about the company, our executive team,
| and our culture. Stay tuned!
|
| You can check out my LI profile for now though ;)
|
| https://www.linkedin.com/in/voidmain/
| mooreds wrote:
| Hiya,
|
| I can't speak for robotdan, but am also an employee.
|
| My opinion: we have been so busy heads down building
| things we haven't put together an about us page.
|
| https://www.linkedin.com/company/fusionauth/ is pretty
| transparent about who works there, though.
|
| HTH.
| NomDePlum wrote:
| I'm curious why that matters?
|
| Part of that curiosity is because the answers so far talk
| about 'About'pages and similar.
|
| What's the added benefit/trust you are looking for here?
|
| Apologies if my question is naive.
| jjeaff wrote:
| To me, the about us page is one of the more difficult
| things to fake and can at least tell you whether the
| company is brand new or maybe owned by a big company or
| just a recent startup.
|
| I have found out quite a few scams by looking at the
| about us page and researching the names on the page. Most
| everyone working in tech had some kind of digital trail
| that would take a lot of effort to fake.
|
| If I get taken for a ride, I want to at least know who is
| going the driving.
| jacquesm wrote:
| 100% agreed on this. Also: because reputations matter.
| neom wrote:
| I thought about that quite a bit before I posted this.
| "why do you care??"
|
| The answer was still just the same: I'm curious who is
| working on this.
|
| So I guess pretty much just curiosity for me.
| sixhobbits wrote:
| +1 - I set up a FusionAuth instance to do a tutorial for them
| and it was a great experience.
| adamcstephens wrote:
| Regulators should block this merger. Consolation is strangling
| capitalism in this country.
| jnwatson wrote:
| Nah. There's so little moat around the SAML/OAuth thing that
| there are already a half dozen startups working in the space,
| not to mention the offerings from the big cloud providers.
|
| I've just completed an Okta integration, and there simply
| isn't much "there" there. It doesn't even really have much of
| a network effect. They will be one player among 5 in the
| space in a couple years.
| OkGoDoIt wrote:
| I used to work on the Okta team that made those libraries. We
| were a tiny team with not nearly enough people.
|
| As far as I could tell, Okta is a sales company. The
| salespeople got the fancy events, the high floors with nice
| views, all the budget. On my orientation day it was almost
| entirely sales people and only one other engineer. Also the pay
| was laughable compared to any of the other jobs I've had before
| or since. I didn't even stay there 5 months, what a shit show.
|
| Another fun story from there: I was literally the only Windows-
| experienced developer in the company at the time, I was
| sometimes approached by unrelated teams that had an issue
| getting something to work on Windows asking for help. I would
| happily help where I could, but then I got chewed out by my
| manager and director for doing so.
|
| Enterprise customers are the only ones that mattered, and
| engineers were expected to keep our heads down and implement
| what was asked and nothing more.
|
| It's a sad day for Auth0. I got to know some people who came
| into Okta via acquisitions and let's just say it's not a fun
| ride.
| TheRealDunkirk wrote:
| What's sadder for our society as a whole is that, despite
| this comment and the GP comment, this is happening, and will
| be allowed to happen by regulators who won't give this a
| second glance. And this sort of multi-billion-dollar
| absorption of a "better" company by a "worse" company is
| almost a weekly story.
|
| Tech started out as a meritocracy, and a lot of us still
| operate personally in a meritocratic bubble, but, generally,
| this hasn't applied for a long time. As a whole, tech is
| leading the way forward in a neo-fuedalistic form of
| government. These political marriages to increase one's
| kingdom are a common affair, and they NEVER work to end-
| users' advantage. They only serve to make the kings and
| princes of the realms involved a lot of money.
|
| The best we tech-end-users can do is grit our teeth, and hope
| that the acquisition doesn't ruin a product that we love and
| depend on. The one I'm still waiting for the other shoe to
| drop on is GitHub. There's a LOT of people on this site
| (among many others) who crow about how Microsoft has changed,
| but time will tell. At the very least GitHub is going to get
| "FOR BUSINESS!" laced all through it. I note, for the record,
| that many of the high-profile Ruby people abandoned ship for
| Shopify after the sale. That's not usually a good sign.
|
| Having been through a "merger of equals" of Fortune 150's --
| and watching my very-good-company-to-work-for being broken up
| and sold for parts to float the bad company's survival --
| I've learned this is all you have to do: watch who leaves and
| who stays. Ignore all the PR statements. They are literally
| worse than nothing. Watch what happens to the core tech
| people, and the distinct VP's. That will tell you what's
| really happening with the restructuring. In my company, the
| ring-1 exec's all cashed out their golden parachutes and
| left. You have to have some inside information to understand
| the players, so this is tough to do from an external
| observer's point of view.
| thrownaway564 wrote:
| "meritocracy" is a banned word at okta. We have a wiki page
| with over 80 words banned and 'discouraged' for inclusivity
|
| definition: "Belief in the flawed idea that hard work and
| talent alone are all that's needed to achieve success."
|
| Thanks Todd!
| TheRealDunkirk wrote:
| Wow. I don't think I could have come up with anything
| more poignant. Thanks for creating a throwaway to point
| that out.
| koffiezet wrote:
| > At the very least GitHub is going to get "FOR BUSINESS!"
| laced all through it.
|
| That already happened, but with no negative impact on its
| public/free side. All we got from it are unlimited private
| repos, and limited github action minutes and repository
| storage in the free tier. I call that a win.
|
| Also, the GitHub sale was 2.5y ago, if things would have
| gone wrong, we would have already seen the cracks.
|
| Ruby devs abandoning GH is simply because they saw the
| writing on the wall that Ruby was not seen as long-term
| viable tech by MS. And from a sysadmin/SRE/devops pov, if
| there is one stack I hated supporting more than JVM-based
| deploys, it's Ruby, so I wouldn't blame them.
| sangnoir wrote:
| > What's sadder for our society as a whole is that, despite
| this comment and the GP comment, this is happening, and
| will be allowed to happen by regulators who won't give this
| a second glance.
|
| Not trying to be trite here, but it shouldn't surprise you
| when an organization with a lot of capital gets its way in
| a capitalist society - all other concerns are secondary.
| It's a feature, not a bug.
| quickthrower2 wrote:
| Been through this on a tiny scale. I won't mention the
| company but basically I believe it was acquired as a short
| term cash cow to finance the mother company that needed
| cash, with the acquisition being financed by going public.
|
| In the short term they could raise prices and fire
| developers and keep the MRR coming in to feed the main
| business. This was a while ago when competitors were
| knocking out impressive web based solutions and they still
| had a desktop app (this is in an area where a web based
| solution made a lot of sense)
| vecinu wrote:
| > Also the pay was laughable compared to any of the other
| jobs I've had before or since.
|
| Really? I'm shocked to hear this considering their successful
| IPO. Most engineers in SV get options and I would imagine
| those engineering options would be worth a lot 12-months post
| IPO.
| blaines wrote:
| I have a couple friends who previously worked for Okta and
| they similarly lamented that the comp was shit and they
| treated folks poorly in the IPO process. For them, it
| wasn't worth it.
| [deleted]
| suddenstutter wrote:
| Also worked at Okta. Can confirm, pay is surprisingly shit.
| dwoot wrote:
| Are the figures on Levels accurate?
| https://www.levels.fyi/company/Okta/salaries/Software-
| Engine...
|
| Seems fairly par for the course?
| skeeter2020 wrote:
| Don't know about the comp levels but the title /
| experience / pay seems totally whacky - a staff-level
| engineer with a total of 5-7 years of experience? IME
| this role is for very experienced ICs who don't move into
| management but are still key leaders.
|
| Has title inflation followed the general trends of post-
| secondary grade inflation?
| bogomipz wrote:
| >"I interviewed with both, and the process at Auth0 had me walk
| away with respect, while contrasted with Okta that left me
| reminded that tech hiring is broken."
|
| While I haven't interviewed with Auth0 it sounds like we both
| had the same experience and impression regarding Okta. You know
| something is off when your interview loop for an engineering
| role involves the President of Technology doing coding
| interviews and all your interviewers warn you about you about
| your upcoming interview with him. I thought it said a lot about
| the culture there.
| Cederfjard wrote:
| Was this long ago? Or is the engineering team really small
| compared to the company as a whole? Google says they're ~2400
| people, seems really weird for the most senior technical
| person in an organization of that size to be conducting
| coding tests with rank and file candidates.
| bogomipz wrote:
| No this was not long ago and the engineering team was
| large. The company was well over 2K people when I
| interviewed. And yes it is very weird to have the President
| of Technology giving coding tests during an interview loop.
| I met with 6 other senior engineers 4 of which had already
| gone over coding. Apparently this is his thing though. The
| purpose of this seemed to be for him to demonstrate how
| smart and hands-on he was. Their in house recruiter
| actually called me the day before the interview and said he
| had to "prep" me for my interview with this person.
| watertom wrote:
| How will market consolidation lead to a smaller viable
| alternative?
| edoceo wrote:
| Nature abhors a vacuum
| rizpanjwani wrote:
| Auth0 is such a joy to work with due to their simple processes
| and amazing documentation! I hope auth0 continues to do well.
| grinich wrote:
| We are doing this at WorkOS. :)
|
| It's like Stripe for enterprise features, including SSO/SAML,
| Directory/SCIM, and more.
|
| https://workos.com/docs
| stanmancan wrote:
| Going to have to check this out tomorrow. Currently we offer
| SSO via Auth0; it works, but it feels messy and there's
| errors I can't seem to track down.
| modulus7 wrote:
| We've been integrating WorkOS with our product. The directory
| syncing is awesome, and the docs are well sorted.
| pulkitpulkit wrote:
| We wanted to roll out SSO for our web app and used WorkOS..
| we looked at Okta, Auth0 and others, but found the out-of-
| the-box nature of WorkOS really compelling. Aligned with
| flexibility and support for a wide-range of services, it made
| our life pretty easy. Recommend
| rogerkirkness wrote:
| We used WorkOS to build SSO into our app. It took about one
| engineer two weeks to build and test.
|
| Compared to Auth0 where you can't really control user
| sessions or access yourself, WorkOS makes way more sense in
| terms of not building all the hard auth extensions for SSO
| and retaining user accounts. It's great so far.
| abraae wrote:
| The problem is that Google, FB, Microsoft and all the other
| "auth providers" are able to deliver a good and free auth
| service because it's subsidised by their other products.
|
| Whereas Okta, Auth0, etc. cannot, since that _is_ their
| product. So they have to charge.
|
| Given network effects, a free auth system will always beat a
| paid one, except where the user is compelled to use it. (e.g.
| you want to use my SaaS product? You'll have to create an
| identity in my private auth system).
|
| So I don't think these products (and I'll include KeyCloak
| which is fricking awesome) really compete as such with the
| FAANG offerings.
| mooreds wrote:
| I am not sure about that. Thee same strengths that FAANG
| brings means that they don't have the intense focus that
| companies like Auth0/Okta/others bring. See how many people
| are complaining about Firebase and Cognito in other threads.
|
| Having the auth system be your primary revenue stream means
| you pay very close attention to it, whether that be marketing
| or engineering. If it is just a freebie/side offereing you
| add to make your core better, well, it might lack resources
| or focus.
|
| Disclosure, I work for FusionAuth.
| arcturus17 wrote:
| I've complained extensively about Firebase in other posts,
| but not about their Auth module which I think is by far the
| best offering in the portfolio of services. I've integrated
| it for a large enterprise customer through SAML and have
| had an extremely positive experience where everything just
| worked with about a morning of work, and I've not had to
| maintain it ever since. The client SDK is great in how it
| syncs auth states with the server.
|
| My main complaint is that there is no 'onLogin' serverless
| functions hook, and how keeping additional user context
| through custom claims is not that straightforward.
|
| And of course I'm pretty apprehensive about Google having
| the data, so best of luck to you all building OSS
| solutions.
| abraae wrote:
| Fair comment.
|
| However I don't see many web sites with a "sign in with
| FusionAuth" button, and I don't see any way to get such a
| button for my site.
|
| Not without paying anyway - which is really my whole point.
| Free will always win.
| mooreds wrote:
| Sure, just like you won't see sites with a 'sign in with
| Auth0' button. Both are service providers.
|
| As a sibling comment mentioned, FusionAuth has a free
| offering if you self host.
| https://fusionauth.io/download/
| chrisbuc wrote:
| I'm just starting a new side project, and have looked at
| Keycloak and fusionauth. Fusionauth has a free offering
| (ie, self hosted), and takes a minute to install and run.
| I like it a lot and am going forward with it for testing.
|
| You won't see a login with fusionauth button, you'll just
| see a login button on my website, which might give you
| Google, github,LinkedIn logins etc depending on what I
| choose.
| advaitruia wrote:
| Depending on what set of features you need, it may make
| sense to also have a look at SuperTokens.io. Probably not
| as mature but we're open source and stronger with
| customization of the end user experience (frontend
| stuff), support and ease of implemenetation.
| mooreds wrote:
| > stronger with customization of the end user experience
|
| I might say "a different approach" :) I appreciate
| SuperToken's SPA first stance, but FusionAuth is pretty
| darn customizable too:
| https://fusionauth.io/docs/v1/tech/themes/
| Tsarbomb wrote:
| I also interviewed at Okta and one of the first interviewers
| started the session by insulting me. Like full stop, insulted
| me. I threw the rest of the interview and enjoyed the free
| lunch.
| hoten wrote:
| Do you mean a verbal insult, or some programming task he
| asked you to do that was far beneath your level?
| Tsarbomb wrote:
| She verbal insulted me and then told me to justify why I
| think I could work at Okta. The whole thing felt like a
| giant bait.
| turtlebits wrote:
| Agreed, I found it hard to write integrations with Okta and
| ended up using Keycloak and integrating it as an OIDC client.
|
| I found Keycloak extremely easy to setup and work with.
| neurostimulant wrote:
| I wish keycloak has smaller memory footprint so I can cram it
| in a small vps together with other small webapps. Other than
| that it's excellent.
| Conan_Kudo wrote:
| There's a Quarkus-based build of Keycloak called Keycloak.X
| that seems to significantly improve this:
| https://www.keycloak.org/2020/12/first-keycloak-x-
| release.ad...
| neurostimulant wrote:
| Oh wow, I should try this version. Thanks!
| ClumsyPilot wrote:
| Yeah, first time I tried to start it i set 128mb limit and
| got nothing at all, was a little surprised
| gabereiser wrote:
| Also have huge extensive experience with keycloak and highly
| recommend it. It's best when used as a custom docker
| container (so you can add your certs) but I've used it to
| build enterprise-wide auth, department level permissions and
| authorization, product level auth, and even SSO to AWS
| console.
| abraae wrote:
| Keycloak is fantastic. You want 2FA? Password expiry? SSO?
| Keycloak does it all. I can't imagine starting any product
| now without considering Keycloak.
| hangonhn wrote:
| 100%.
|
| We use Okta but to write some integration with their OIDC
| service, I found it much easier and secure to use the Auth0
| libraries. I found Okta's support to be really lacking. And
| while features like Token Exchange has been in draft form for 5
| years and finalized a year ago, Okta still hasn't implemented
| and their beta won't be ready until later this year.
|
| Not a fan of Okta but their business model does have really
| good vendor lock-in.
| Spooky23 wrote:
| Okta is one of the more disappointing companies for me.
|
| In the enterprise space, imo Microsoft is going to eat
| everyone's lunch. Azure AD is pretty transformative, and their
| public facing stuff isn't that far apart from what Okta does.
| bootyfarm wrote:
| RIP Stormpath RIP Auth0
| tootie wrote:
| Wow. These guys were basically 1 and 2 when it comes to
| enterprise auth/CIAM. It's great news for the businesses, but
| will likely only decrease competition in the marketplace. There's
| a ton of second tier competitors out there with plausible
| offerings who are probably going to start consolidating to stay
| alive.
| namdnay wrote:
| Wouldn't 1 be Microsoft?
| tootie wrote:
| They're not really doing the same thing but you're probably
| correct that most customers are just relying on AD. I can
| easily imagine MS beefing up their identity offering to be
| more on par with Okta.
| trevorishere wrote:
| We replaced Okta with Azure AD. AAD had better OIDC and
| SCIM support along with being _significantly_ less
| expensive -- plus we had to use it anyways due to
| M365/Azure, so Okta offered no value.
| tootie wrote:
| I assume that's for enterprise, not customers.
| trevorishere wrote:
| Correct, though we do use Azure B2C with 3rd parties, as
| well.
| femto113 wrote:
| Amazon/AWS and Google are big in the identity space too, so I
| think it makes sense that there's only room one real "third
| party" option.
| tootie wrote:
| Cognito and Firebase are bush league by comparison. They
| can do the basics well enough if you have the right
| integration engineers. Okta and Auth0 are light years
| ahead.
| femto113 wrote:
| The difference is that Okta/Auth0 is never going to be
| the only piece of a solution. With AWS it's more than
| just Cognito, you have to consider IAM and SSO as part of
| the equation as well. And if you're a pure AWS shop the
| AWSness of Cognito (or its direct support in API Gateway,
| etc.) might make you prefer it to Okta or Auth0
| regardless of feature parity. For Google the key asset is
| really Gmail/GSuite/Workspace, which is the primary
| identity provider for many, many organizations (and the
| sole identity provider for most of those). However kludgy
| Google's built in SAML stuff is there is a huge value in
| only needing to deal with one entity.
| pirate787 wrote:
| Cognito is a nightmare and many things are broken. I lost
| 3 weeks in Feb. on a project trying to get it to work and
| just integrated Auth0 in 2 days.
| jessaustin wrote:
| It might be better for these two to merge than for either
| (or both!) to be subsumed into those much larger firms.
| This is why FTC allowed Sirius and XM to merge: to keep
| them both out of the clutches of larger firms who would
| have seriously considered killing satellite radio
| altogether.
|
| [EDIT:] Of course, this merger may just be a ploy to drive
| up the price of a future merger with one of the larger
| firms...
| andrewstuart2 wrote:
| I know it doesn't cover everything Auth0 and Okta presumably
| provide, but Keycloak is OSS and has RedHat support, and is
| honestly one of the best IDPs I've ever used in terms of
| capabilities and friendliness. I know there's also the ory
| suite in the more cloud-native/recent space, though I can't
| personally speak to its maturity.
|
| Maybe I'm biased by the large bank I currently work at, but in
| general, it seems like IAM is the last thing we really want
| outsourced/closed source and monocultured. If they lose the
| motivation to stay ahead of the competition, and stop
| responding to vulnerabilities as quickly as they ought to, it's
| not just their company that loses.
| octopoc wrote:
| I've started using KeyCloak by default for my personal
| projects. Once you know how to integrate it and configure it,
| you never have to worry about users or roles again. I haven't
| used the groups feature yet but I'm optimistic considering
| how easy Keycloak is to configure. Overall it's a great tool
| to have in your tool belt.
| wp381640 wrote:
| Lack of webauthn might be a stopper for some, but it's in
| the pipeline:
|
| https://github.com/keycloak/keycloak-
| community/blob/master/d...
| p_l wrote:
| Huh, I'm pretty sure it's present by default (not behind
| a flag) in current versions of Keycloak - would have
| liked to use it but our setup is so heavily firewalled
| tokens wouldn't make it over ;)
| wp381640 wrote:
| I'm going to check it out again today because last eval I
| did with this requirement was ~10 months ago
| octopoc wrote:
| Yeah there's a tab for it in the latest docker images,
| although I've never configured it
| wp381640 wrote:
| It's there! Awesome. Thank you.
| p_l wrote:
| Please make a write up about using it - my current use of
| keycloak doesn't fit webauthn (clients access it from
| virtual workstations that don't have usb access) but I'd
| like to incorporate it further in my toolbox for future
| projects
| wp381640 wrote:
| I may do just that and add it to the docs - thanks for
| the tip
| andrewstuart2 wrote:
| There's just so much value in the fact that I can run it
| locally, deploy it wherever, play with it and learn it for
| free and even feel safe enough to expose it publicly due to
| its maturity and backing. As long as I stick with the
| standards (remind yourself and your users "you build OpenID
| Connect clients, not 'keycloak' clients," I can even
| (easily) move somewhere else if I want, and now I
| understand Oauth2/OIDC better and probably have a much more
| scalable authn/z system in place thanks to the way
| federated authn asks you to design your (fine-grained)
| authz.
| mooreds wrote:
| > It's great news for the businesses,
|
| I assume you mean they'll be able to get monopolistic rents
| now?
|
| The other alternative is that Auth0 customers will be forced
| into Okta plans and migrate to other platforms. It's happened
| before with other mergers.
|
| Disclosure: I work for a competitor.
| nl wrote:
| Ping and Sailfish are big companies too.
| nl wrote:
| Sorry, this should be Sailpoint of course.
|
| Okta, 2020 Revenue: $586M
|
| Sailpoint, 2020 Revenue: $355M
|
| Ping: 2020 Revenue: $224M
|
| Auth0, 2020 Revenue: $200M
|
| There's also Oracle ID Manager, some IBM thing etc - a bunch
| of other large vendors.
| death_by_ppt wrote:
| I think you quoted the wrong number for Okta's revenue. The
| first hit on Google said:
|
| > Okta revenue for the twelve months ending October 31,
| 2020 was $768M, a 43.77% increase year-over-year. Okta
| annual revenue for 2020 was $586M, a 46.79% increase from
| 2019.
| nl wrote:
| I was quoting 2020 financial year numbers. As per your
| quote: "Okta annual revenue for 2020 was $586M"
| korginator wrote:
| I only hope and pray that Auth0 doesn't give up on their
| attention to documentation, examples, and just making it easy to
| get going with their ecosystem.
|
| It took me a couple of hours to get a Spring Boot application to
| use Auth0 as an IDP and for ID federation to AzureAD, Google,
| Apple, and a few other IDPs. The documentation and examples are
| very comprehensive, and I like how they really get the day to day
| problems faced by developers.
|
| Getting anything working with Okta on the other hand took ages
| longer, to the point that we gave up on them to move to Auth0.
|
| In all, this acquisition is bittersweet for me.
| politelemon wrote:
| > and integrated over time
|
| I'm reading too much into this sentence fragment and it fills me
| with fear.
|
| I smell breaking domain changes in the future. They can't allow
| the .auth0.com tenants to operate as-is forever, which means
| existing tenants will get grandfathered in and eventually forced
| off the .auth0.com domain onto okta's domains.
|
| I smell messy login sites in the future. I like Auth0's
| implementation of their Universal Login page, which didn't
| require JavaScript. In the quest for 'one single brand identity'
| someone will force a migration to Okta's login implementation
| instead.
|
| That will come with changing client IDs, client secrets, M2Ms and
| everything else needed in their setup.
|
| I might as well create a Jira ticket for this now.
| r00fus wrote:
| > They can't allow the .auth0.com tenants to operate as-is
| forever
|
| Why not?
| capableweb wrote:
| Because Okta just acquired Auth0. If we look at previous
| acquisitions, the usual flow is something like this:
|
| 1) Company A acquires company B, promises nothing will change
|
| 2) Company A hints that company B will slowly be integrated
| into Company A
|
| 3) Everything Company B did becomes deprecated and migration
| plans are made for 70% of features to get integrated into
| Company A
|
| 4) Users who need the rest of 30% need to find a different
| service when things start to get turned off
|
| I see no reason why this Okta/Auth0 acquisition would be
| different. Especially anything that is branded as Auth0 will
| disappear or get renamed to Okta. So at least the domain will
| change, which will require both infrastructure, backend and
| frontend changes most likely. Sucks, as the change is not
| needed and doesn't improve anything, it's just needed for
| Okta to rebrand Auth0.
| r00fus wrote:
| There are companies that keep purchased brands for years
| and years. Costs may go up as it becomes "legacy", but
| corporations do what makes sense.
|
| To assume any product/brand is going to exist indefinitely
| is unrealistic unless you as a customer have that in your
| contract (and even then mergers break this routinely).
| bena wrote:
| So you're not fond of them?
|
| I have limited exposure. We use them at my place of work for
| 2fa for our VPN. And an organization we work with uses it for
| authentication.
|
| But I haven't had to use them in anything I've developed.
| DaiPlusPlus wrote:
| The idea of _outsourced identity_ is just so contradictory it
| makes my blood pressure shoot up when people sincerely
| suggest it.
|
| I'll make an exception for Office 365 / AAD when an
| organization has already got their userbase added, but after
| that I'd wager if an org is big enough to need their own
| federated authX, then they're big enough to deploy
| IdentityServer and be done with it.
| oftenwrong wrote:
| That's a bad wager to make. In B2B it's not unusual for
| small, under-resourced companies to have big customers that
| all require an integration with their own identity
| solutions.
| DaiPlusPlus wrote:
| That's my point: IdentityServer (for example) is what
| enables any org capable of running a website themselves
| to integrate with other OIDC-conformant identity
| solutions via federation without having to cede any
| control over their own data.
| capableweb wrote:
| Welcome to the future of the internet and web! Originally
| everyone was supposed to run their own servers and
| websites, but instead we have... The cloud?
|
| Hardly surprising that it didn't stop with that, and today
| you can basically build an app on 100% rented
| hardware/software via services. So if we're already
| outsourcing everything else, why not identity?
| robotdan wrote:
| >> and integrated over time > I'm reading too much into this
| sentence fragment and it fills me with fear.
|
| Lol!
| tomashertus wrote:
| Congratulations to the entire Auth0 team. I admire their strategy
| on selling comprehensive auth/CIAM solution to the developer
| teams from all around the world!
| [deleted]
| davewritescode wrote:
| We use Okta for a bunch of stuff and I do really love their
| product. My company did two rounds of evaluation and really loved
| Auth0 but their product was unfortunately too opinionated about
| some things which made it difficult to adopt.
|
| I don't know what this means regarding costs but for my place of
| business we saved money versus hiring people to operate/maintain
| the system.
| grinich wrote:
| I would love to learn more about what you found too
| opinionated. (I work at WorkOS.)
|
| Can you shoot me a DM? I'll "buy you lunch" aka send you a
| Doordash gift certificate as thanks :)
| dyeje wrote:
| Does this rise to the level of antitrust scrutiny? Aren't these
| like the two biggest SSO providers?
| ROARosen wrote:
| In a way I think this is good for consumers as it positions
| them better to counterbalance Microsoft, the big bear in the
| field.
| tpmx wrote:
| I'd think so, but in the US antitrust isn't really much of a
| thing. I wonder if they have grown large enough in Europe
| yet...
| sojournerc wrote:
| I'm curious why you think anti-trust isn't a thing in the
| US...
|
| What do you think of the break-up of Bell Systems?
| https://en.wikipedia.org/wiki/Breakup_of_the_Bell_System
|
| There are also active anti-trust investigations into Google
| and Facebook.
|
| https://www.cnn.com/2020/12/17/tech/google-antitrust-
| lawsuit... https://www.forbes.com/advisor/investing/facebook-
| antitrust-...
| pottertheotter wrote:
| I think tpmx means antitrust isn't currently much of a
| thing in the US, and I agree. Today's antitrust environment
| is a far cry from even the days of Bell.
| ahallock wrote:
| A little, but I don't even think they're the biggest.
| manigandham wrote:
| Biggest but not a monopoly. There are numerous competitors from
| open-source to managed versions.
|
| Every major cloud also has an auth/identity product and
| collectively probably have more total customers at this point.
| bdcravens wrote:
| Except that AWS and Google have their own offerings (and the I
| think these aren't SSO companies as much as Auth as a Service
| providers)
| davewritescode wrote:
| If Cognito is the AWS offering you're talking about then it
| doesn't even begin to compete. It's really a terrible product
| and AWS has misled us about the roadmap multiple times
| specifically in relation to multi-region support.
|
| When AWS Cognito had it's outage in November, I was quite
| happy we went with Okta.
| bdcravens wrote:
| I'm unimpressed with it as well, but I suspect antitrust
| officials have a different definition of "competition" than
| we do.
| motives wrote:
| Azure AD is the biggest in the game by far in terms of SSO,
| stretching every vertical from education to investment
| banking.
| DaiPlusPlus wrote:
| ...only because of Office 365 though.
| softveda wrote:
| Azure AD B2C for customer IAM is lagging way behind
| Okta/Auth0 etc. Sure AAD is great enterprise users or B2B
| but millions of customer login, branding, app experience
| B2C sucks.
| bnjms wrote:
| Disney bought Fox and Amazon both sells 1st party and 3rd party
| goods. So I'd say no.
| staysaasy wrote:
| Had exactly the same thought - this seems like it's begging for
| the antitrust hammer.
| [deleted]
| RazorX wrote:
| Oof, I really like Auth0 and was thinking of adopting them soon.
| Now it just seems like a huge risk. Why would I willfully walk
| into what will obviously be a migration nightmare and unknown
| pricing change for one of the central and critical pieces of my
| application (which should be boring to maintain)?
|
| Best to Auth0! I really hope you can maintain your company
| culture and excellence, but I can't risk my business on that now.
| polskibus wrote:
| How much value is there in okta/auth0 than there is in open
| source Keycloak?
| throw1234651234 wrote:
| Tragic. All Auth options are horrible and overpriced. From a
| presentation I did for a client a year ago for only 10,000 users:
|
| Off-the-shelf auth cost comparison * Okta: $20,000 / month *
| Auth0: $1,500+ / month * These are barebones services - any
| customization would cost extra * There is still a large
| implementation code when using these services
|
| Auth0 was worth using for midsize companies sometimes. Okta is
| not.
| death_by_ppt wrote:
| That doesn't seem to match the pricing on
| https://www.okta.com/pricing . It's more like $200/mo for the
| Developer tier, $3,500/mo for the Enterprise tier.
| aguynamedben wrote:
| We're using WorkOS to build Directory/SCIM and are very happy
| with it. They have a really good API for syncing enterprise
| directories (G Suite, Okta, SCIM, Azuer, etc.) and webhooks to
| get changes.
|
| It's easy enough to use even for internal applications, but we're
| using it to integrate customer directories with our product.
|
| We're also using it to do SSO for our product. It's much easier
| than trying to integrate with each of these systems.
| Black101 wrote:
| another crazy valuation
| no-dr-onboard wrote:
| One auth to rule them all.
| dataminded wrote:
| I've done a couple of successful Auth0 projects. Okta has always
| been impossible to work with. Time to find another vendor.
| [deleted]
| yalogin wrote:
| I wonder why the stock tanker after this is announced. From what
| I see they are the top 2 players in this space and so an
| acquisition should be good for business.
| nickysielicki wrote:
| $6,500,000,000.00 for a company providing authentication APIs?
|
| Am I the only person left on earth that hasn't lost his mind?
| omni wrote:
| Check out Auth0's pricing page and it might start to make sense
| to you, they're outrageously expensive
| mooreds wrote:
| Or the numbers in this comment:
|
| https://news.ycombinator.com/item?id=26334736
| TruthWillHurt wrote:
| Not more expensive than Looker at ~$6000pcm. Also Looker is
| category leader whereas Auth0 is struggling to compete
| against cloud-provider supplied solutions (Cognito/Google
| Auth).
| PragmaticPulp wrote:
| It's for the business and the users, obviously. Not just an
| API.
|
| If it was easy to amass this many paying customers, surely
| other competitors would have rushed in to compete, right?
| whalesalad wrote:
| I'm completely shocked by this as well. This is the most insane
| valuation I've seen in a while.
| dilyevsky wrote:
| Have you ever heard of Snowflake?
| ggregoire wrote:
| Salesforce acquired Slack for $27.7 billion 2 months ago.
| notsureaboutpg wrote:
| Slack is, imo, a way more complicated, way more valuable
| service targeted at a larger market than Auth0.
| notsureaboutpg wrote:
| I'm using a service (Hasura) to build out a backend and all
| their docs recommend Auth0 as a JWT/authentication service but
| the pricing is outrageous. I spent 3 days and built a version
| myself which is just fine and can be changed whenever / however
| we want.
|
| Google / Facebook / Apple authentication are not hard to
| implement at all, maybe I'm missing the actual value they
| add...
| tyingq wrote:
| Enterprise customers with Enterprisey wallets.
|
| Edit: Ping Identity might be a good place to invest, they look
| a bit low right now, and they support cloud and on-prem.
| spydum wrote:
| And own huge chunks of the enterprise market (and customers
| are generally happy at least in my circles).
| e_y_ wrote:
| That sounds crazy to me too. By comparison, Microsoft paid
| $7.5B for Github and Google paid $2.6B for Looker.
|
| Idaptive, another IdP (I don't know how it compares in terms of
| features or client base) was bought by Cyberark for a mere
| $70M.
| randomsearch wrote:
| Makes GitHub look like the buy of the century. Which it may
| well turn out to be.
| ThankYouBernard wrote:
| Yes, you're the only one who can see the truth in the whole
| world. We all know that
|
| Slack = just IRC
|
| Dropbox = just rsync
|
| Twitter = just a weekend project
|
| etc
| hyperpl wrote:
| I'm in the same boat and I use okta for work and have no clue
| what the hell it does or why this just can't be accomplished
| using open source.
| softveda wrote:
| Identity is a very sensitive area with strict cryptography
| and compliance requirement regarding password hashing, token
| signing etc. Then they have to keep updated with ever
| changing OAUTH/SAML standards and integration with providers
| like Facebook/Google etc. They have to get audited and
| certified like ISO 27001, HiTRUST etc. These are very
| expensive to manage and high risk for non-tech companies
| (think banks, insurance, utilities etc.) and hence are
| outsourced.
| jpgvm wrote:
| Whilst there certainly are great OSS solutions most big-ish
| corps already have Active Directory. You can setup ADFS to do
| SAML for SSO or you can use Azure AD which already has all
| that out of the box.
|
| If you aren't a big-ish corp then yeah, there are tons of OSS
| ways of doing IdP that fit your specific tastes etc.
| anderspitman wrote:
| Centralized services gonna centralize.
|
| Something I've been thinking about recently is that a full web
| browser is a hard dependency of OAuth2-based systems. That's
| 20-30 million lines of code even for the simplest systems, even
| though you're basically just using the browser as a form renderer
| and a central space to store tokens.
|
| I feel like there's room for a simpler protocol designed to
| operate on HTTP plus a minimal UI language (maybe JSON-based)
| used to describe forms for granting access. This would make it
| much easier to develop for devices that don't have browsers. You
| could even make CLI interfaces for authorization flows.
| mooreds wrote:
| You might want to check out GNAP. I did an overview of it here:
| https://fusionauth.io/blog/2021/01/07/gnap-next-gen-oauth/ but
| you can also check out the spec here:
| https://datatracker.ietf.org/doc/draft-ietf-gnap-core-protoc...
|
| They are aware of the issues of the browser centricity of
| OAuth.
|
| It's definitely not the simpler protocol you describe, but it's
| one way to look at the future.
| BerislavLopac wrote:
| At one startup I had to switch from Stormpath to Auth0 because
| the former was acquired by Okta...
| corytheboyd wrote:
| Oh my, I hope the Auth0 free tier doesn't change because I just
| built out an integration with them for a project. Oh well, the
| end game was always to build my own auth, just... later, because
| it's such an annoying mountain of work.
| mean_gene_1976 wrote:
| I am honestly not aware of either companies. From the outside
| looking in, the business model appears to be selling X as a
| service covered in buzz words. I mean enterprises check the box
| on these requirements. Now Hashicorp, they excite me.
| mooreds wrote:
| If anyone's looking for an Auth0 alternative, come check out
| FusionAuth!
|
| It's been built from the ground up for developer experience with
| a distinct lack of jargon, amazing customizability, an API first
| approach and great docs. Plus, enterprise features too, including
| SSO/SAML, OIDC, and more.
|
| https://fusionauth.io/docs/
|
| (I work at FusionAuth.)
| grinich wrote:
| lol did you copy my comment? :P
| https://news.ycombinator.com/item?id=26335608
| mooreds wrote:
| Sure did, figured it was open season :) Still got downvoted,
| oh well.
| agentdrtran wrote:
| Unfortunate. Okta is working on their monopoly.
| bashmohandes wrote:
| Microsoft is in this space you know, it is by far the biggest
| player.
| switch007 wrote:
| How does one migrate your users away from Auth0 seamlessly as
| possible (when you're using their Database connection)?
|
| I seem to recall something about raising a ticket for an export
| including the hashes?
| brokenwren wrote:
| You can export everything via a support ticket. We have
| migration scripts you can use if you come over to FusionAuth or
| tweak them for any other platforms as well:
|
| https://github.com/FusionAuth/fusionauth-import-scripts
| f430 wrote:
| okay so short okta
|
| got it
| invokestatic wrote:
| There's something about Okta that just scares me. If Okta is ever
| compromised, so are the thousands of companies that rely on it
| for IdP. How do companies mitigate this risk? Or do they?
| temuze wrote:
| That's the same fear some people have about password
| managers...
|
| IMO, the answer is simple: I would rather security be done by a
| company where security is THE feature. In other words, I trust
| 1Password's security team over, say, Hulu's or something.
| rurp wrote:
| Sure, but it's not a 1-1 comparison. If Hulu gets compromised
| you only lose your (hopefully unique) Hulu credentials. If
| your password manager gets compromised a single attacker gets
| access to _all_ of your accounts. The security standard for a
| password manager is much, much higher than pretty much any
| other service.
|
| Password managers are still the best option for most cases,
| but having to put such an incredible amount of trust in a
| single company certainly makes me nervous.
| JMTQp8lwXL wrote:
| The problem is a password manager becomes such a valuable
| target. Sure, they have more security resources given the
| nature of their business, but it's that password management
| company's security staff versus a world's-sized quantity of
| potential bad actors, and one of those two groups has more
| resources than the other.
| stormbeta wrote:
| Exactly.
|
| I felt a lot safer using something like KeePass, and
| synchronizing the encrypted database using something like
| Dropbox.
|
| There's not a central target that would get caught up in
| large scale attacks aside from Dropbox itself - and even
| if they get access to that somehow, they'd then have to
| care about me specifically enough to run expensive
| offline attacks on the encrypted database. Anyone
| targeting me directly with those kinds of resources
| already has better avenues of attack.
| jokethrowaway wrote:
| Not only password managers, popular OS as well. We may extend
| it to hardware as well but that's even harder to tell.
|
| I don't trust password managers for sensitive data but
| they're fine for most web account with limited capabilities.
|
| I made my own secret manager based on gpg/age (literally a 5
| lines bash script) and I don't run it from any proprietary
| OS, like Mac OS X or Android. I trust my Arch Linux
| installation a bit more as I know which packages are
| installed or updated and I know what's running on it. Also I
| think an attack is less likely. I also have a separate system
| to share secrets across devices which allow me to setup a
| public/private keypair (+password) on every device and then
| share links on unsafe channels (like consumer chat
| applications or email).
| adrr wrote:
| Office365 is larger and it was compromised. Onelogin was
| compromised and I had my secret keys stored in their vault. I
| spent all weekend rolling new keys.
| bonestamp2 wrote:
| I have okta accounts with a few companies and they all require
| 2FA. I hope Okta is configured so that if Okta itself were
| compromised, the 2FA would still be required to leverage the
| authentication vectors in okta.
| jfengel wrote:
| If Okta is ever compromised, they have a team of people working
| 24 hours a day to deal with it as quickly as possible. And, of
| course, to prevent it from happening.
|
| When it comes to security, it's often a pretty good idea to put
| all of your eggs in one basket, and then make sure it's a
| really, really good basket. Unless you're certain you can make
| a better basket yourself -- and when it comes to auth, there
| are a lot of ways to make bad baskets -- it's better to use
| somebody else's basket.
|
| It's not perfect, but I know I'm not an expert in auth. I use
| Auth0 and then get on with the rest of my work.
| the_duke wrote:
| You are arguing from the perspective of a single company,
| while the parent is arguing from an ecosystem perspective.
|
| Sure, for a single customer it's good to have a widely used
| product with a big ops and security response team.
|
| But if so many companies use a single provider, the fallout
| of a compromise also becomes much larger. This makes
| attacking the system more appealing and attracts more
| sophisticated adversaries, including state actors.
|
| Also, size doesn't necessarily lead to a better, more secure
| product. It often does for well-run, modern IT companies.
|
| But any familiarity with the enterprise software space is
| quite sobering in this regard.
| mooreds wrote:
| Monocultures are more efficient, until they aren't.
| invokestatic wrote:
| I've heard the exact opposite for security: defense-in-depth.
| For example, IdP with Okta and 2FA with Duo. This seems much
| better to me.
| diatone wrote:
| Agreed.
|
| To add something useful to the conversation & giving the
| benefit of the doubt: maybe the parent was describing a
| situation where an org didn't have a cohesive security
| plan. If half your people are using one service, and the
| other half are using another, you've got a problem. I
| suppose this can blow out in complexity, and maybe risk(?),
| once you're stacking services (IdP, MFA, ...).
| JMTQp8lwXL wrote:
| What if AWS was compromised and every DynamoDB instance was
| accessible?
| invokestatic wrote:
| I think the difference is that the scope of DynamoDB is
| limited. A breach in authentication could result in the
| complete compromise of a company.
| sebmellen wrote:
| But use of S3, for example, is not limited much at all. It
| is very dominant.
| londons_explore wrote:
| I suspect that a breach of most companies AWS accounts
| would lead to a complete breach of that company.
|
| Somewhere in the mountains of data stored in an AWS account
| and all it's associated EC2 instances and backups on S3
| will be credentials or information to thoroughly breach all
| other systems.
| codingslave wrote:
| You literally just made this up based on nothing
| tekno45 wrote:
| Someone is able to bypass very strict security and even if I
| went with a different or self hosted solution, if I was the
| target i would be got.
| ablekh wrote:
| Good for Okta and, potentially, for Auth0. But, most likely, not
| so good for current Auth0 users and future IdM users. I believe
| that decreased competition due to industry consolidation is not a
| good thing. I would rather see Auth0 choosing the IPO (or direct
| listing) route for an "exit" ...
| pid_0 wrote:
| ajfdoij23j3oijfnj112121212
___________________________________________________________________
(page generated 2021-03-04 23:02 UTC)