[HN Gopher] The reason Okta spent $6.5B on Auth0
___________________________________________________________________
The reason Okta spent $6.5B on Auth0
Author : advaitruia
Score : 154 points
Date : 2021-03-05 16:02 UTC (6 hours ago)
(HTM) web link (supertokens.io)
(TXT) w3m dump (supertokens.io)
| pdx6 wrote:
| Not long ago I worked at Okta, and I know their engineering
| process pretty well. If I were to speculate on the purchase on
| Auth0, it would be to get more engineers improving the Okta
| platform. There are some really hard scaling problems and some
| really hard security problems, and absorbing Auth0's talent is a
| way to acquire specialty talent in a narrow space.
|
| Finding the right engineer who can program securely, scale, and
| make the developer empathy painless is a key challenge. This is
| what Okta did with Stormpath before the IPO.
|
| (Disclosure: long OKTA)
| tofuahdude wrote:
| Having integrated both... Okta is an awful product and Auth0 is
| an excellent product. Night and day difference in quality.
| grinich wrote:
| If anyone's looking for an Auth0 alternative, I recommend
| checking out WorkOS.
|
| It's like Stripe for enterprise features, including SSO/SAML,
| Directory/SCIM, and more.
|
| https://workos.com/docs
|
| (I'm the founder. Hope it's still ok to shamelessly plug your
| startup on HN. :) )
| pm90 wrote:
| Please plug away. I was so pleasantly surprised to view
| documentation that did not suck, and was a pleasure to read.
|
| After going through the Sisyphean ordeal of trying to read and
| understand okta's api docs for so long, this was a breath of
| fresh air. While my current org is locked on to okta, will
| definitely consider/recommend this for future efforts.
| egberts wrote:
| Okta's core strength is in her predominately salespeople;
| programmers, not so much.
| disgrunt wrote:
| Anyone want to start a competing SSO service?
| erulabs wrote:
| Take a look at the site this blog is posted on ;)
| vangelis wrote:
| You could probably make money on Shibboleth consulting.
| toomuchtodo wrote:
| WorkOS, FusionAuth, Keycloak, the ecosystem is flush. Vote with
| your dollars and your implementation.
| dv_dt wrote:
| What are the interesting contrasts & differentiators in the
| ecosystem in your opinion?
| mooreds wrote:
| I work for FusionAuth and we have some comparisons on our
| website, but I haven't built an application with each of
| these.
|
| I'd say that dimensions that matter vary so widely for each
| person and use case, it'd be hard to do a great comparison.
|
| Dimensions that matter: * open source or
| not * standalone application or library/framework
| you integrate * self hosted or SaaS *
| authentication, authorization, user management or all
| three? * standards implementation *
| integrations with other auth tech (LDAP) * which
| OAuth grants they support * documentation and
| developer experience
|
| And that doesn't get into specific features that you might
| need. An example: if you want to modify a user object in
| the middle of a login flow, Auth0 has rules, we have
| Lambdas, Keycloak has plugins. How are you going to know
| what features you need without building out at least a
| sample app?
|
| Oh, and pricing! Lots of the smaller operations (us
| included) have transparent pricing, but Okta/Auth0 don't.
|
| I wrote out a list of 13 different use cases for FusionAuth
| ( https://github.com/fusionauth/fusionauth-
| issues/issues/1002 ) and I am still discovering new ways
| this coiuld be used. I'm sure that is the case with all
| these competitors.
|
| It's the old elephant story:
| https://www.peacecorps.gov/educators/resources/story-
| blind-m...
| advaitruia wrote:
| + supertokens.io
| toomuchtodo wrote:
| Mea culpa.
| gaogao wrote:
| Clerk, who top paged recently
| https://news.ycombinator.com/item?id=26069621, could compete on
| that front.
| colinclerk wrote:
| Thanks for the mention :)
|
| Come join us! We're building similar react components for
| creating and managing organizations, including a self-serve
| way for IT admins to setup SSO for their org.
| pc86 wrote:
| I'm not sure folks considering Okta are also considering
| 18-month old competitors charge $0.05/user. Other comments
| here place Okta at $2-15/user/month depending on feature-set
| so it's hard to imagine there's anything close to feature
| parity with that pricing spread.
| naringas wrote:
| Looks like this is only good for people whose chief activity is
| "owning stuff".
|
| Everybody else (specifically people who actually execute actions,
| build stuff) loses.
| [deleted]
| colinclerk wrote:
| My take on this is a little different. (Disc: I'm a cofounder of
| Clerk which is also in the space)
|
| I think Okta will try to build "Okta for Customer ID"
|
| When people think of Okta, they think of it as a tool to help
| employees securely access third-party SaaS vendors.
|
| That same problem exists for Customer Identity, but it looks a
| little different. Instead of setting up SSO for SaaS, developers
| are writing code to pass their customer data into tools like
| Stripe, Intercom, Salesforce, Segment, Mailchimp, etc, etc.
|
| This is redundant work that a centralized Customer identity
| provider has the potential to alleviate.
|
| I don't really think Auth0 is well-positioned to pull this off,
| and that's part of why we started Clerk. But considering Okta has
| that playbook in it's DNA, I wouldn't be surprised if that's what
| they're attempting.
| ucarion wrote:
| Why aren't all the existing products in ETL-for-marketers space
| already the answer to the question you pose?
|
| Most companies have a users table, and there are a ton of
| products that can, without code, ETL a users table into all
| sorts of tools. There's no redundant work -- in fact, for
| developers there may not be any work to do at all?
| colinclerk wrote:
| Because they don't know confidently which user is logged in.
| A lot of the marketing tools rely on insecure signals, like a
| userID passed directly from javascript.
|
| If you want to trigger actions rather than observe them, you
| need a secure way of authenticating those actions. That's why
| Clerk does session management :)
| ucarion wrote:
| Let me make sure I understand you: I think you're talking
| about accurate attribution of clickstream analytics to
| particular users, in the face of spoofed data from clients?
|
| And then, connecting the dots a bit, spoofed clickstream
| events could trigger some sort of marketing campaign event
| or other "action" that can become a vector for security
| issues, such as Eve figuring out what Adam has in his
| shopping cart by manipulating a cart-abandoned campaign to
| go to Eve's email instead of Adam's?
|
| If so, this is usually addressed by server-side analytics
| events. I fail to see any mechanism by which this could be
| solved client-side, nor any useful way for any vendor to
| make this process meaningfully easier. Analytics events are
| basically as easy as console.log with most vendors.
| colinclerk wrote:
| Sorry about that, I think I cluttered my response by
| talking about the client-side use case.
|
| Does anybody use ETL-for-marketers tools to extract User
| data from one source, then load it into Stripe as
| Customer objects?
|
| I don't think it's common. We mostly see developers
| creating Stripe Customer objects themselves in their
| backend.
|
| If I understood your original question correctly, you
| were asking why ETL tools don't do this? I think it's
| because these tools are deliberately capable of working
| with fuzzy data streams, so it at least feels weird to
| start using them for secure actions. Their security model
| may also make it dangerous to try.
|
| ---
|
| Somewhat aside: Authenticating actions from the client is
| most-easily solved by signing JWTs. Tools like Hasura are
| doing this in the wild, though it isn't too common among
| third-party APIs yet. The closest example may be
| Intercom, which asks you to sign the user data you pass
| in: https://developers.intercom.com/installing-
| intercom/docs/ios...
| ignoramous wrote:
| > _But considering Okta has that playbook in it 's DNA, I
| wouldn't be surprised if that's what they're attempting._
|
| I'm sorry; Okta has _which_ playbook in its DNA?
| colinclerk wrote:
| Third party integrations
| sokoloff wrote:
| > When people think of Okta, they think of it as a tool to help
| employees securely access third-party SaaS vendors.
|
| That's how I think of Auth0.
|
| I think of Okta as the more expensive, less flexible, slower
| moving, harder to deal with competitor to Auth0.
| nailer wrote:
| Does the ~S~E~C~ (edit: FTC) have to approve? If so, have they?
|
| https://en.wikipedia.org/wiki/Hart%E2%80%93Scott%E2%80%93Rod...
|
| -------------------------
|
| The general rule is that a filing is required if three tests are
| met: *
|
| (1) the transaction affects U.S. commerce;
|
| (2) either (a) one of the parties has annual
| sales or total assets of $151.7 million[3] or more (as of 2014:
| in 2012 this threshold amount began increasing periodically under
| the law), and the other party has sales or assets of $15.2
| million[3] or more (as of 2014: this amount adjusts periodically)
| (where an acquired person is not engaged in manufacturing, only
| its total assets, not its sales, are counted, unless its sales
| are over $151.7 million[3]); or (b) the amount of
| stock the acquirer has is valued at $272.8 million or more (as of
| 2012: amount adjusts periodically) at any time; and
|
| (3) the value of the securities or assets of the other party held
| by the acquirer after the transaction is $68.2 million or more
| (as of 2012: amount adjusts periodically).[4] The 2018 rules
| raise this amount to US$84.4 million [5]
|
| -------------------------
|
| * IANAL, but I worked somewhere that was charged with violating
| the act and it's _any_ of the three, not _all_ of them.
| staysaasy wrote:
| They will need to for a transaction of this size, and the
| approval process is most likely ongoing (and will continue for
| the next few months).
| lvzwilson wrote:
| FYI, it is not the SEC that approves mergers with respect to
| antitrust concerns, but rather the FTC or DOJ. See
| https://www.ftc.gov/news-events/media-resources/mergers-and-...
| advisedwang wrote:
| I'd like to see the FTC get involved. Seems like this is going
| to reduce competition.
| toomuchtodo wrote:
| https://www.ftc.gov/contact
| pc86 wrote:
| Any merger or acquisition by definition reduces competition,
| but these two are far from the only players in the IDMS
| market.
| wpietri wrote:
| I think that's often true, but it's not true by definition.
| For example, if a large company in industry X buys a small
| company in industry Y as a way of entering a market,
| competition can go up in industry Y as the small company
| now has increased capacity to compete with the bigger
| players.
| dang wrote:
| Recent and related:
|
| _Okta to Acquire Auth0 for $6.5B_ -
| https://news.ycombinator.com/item?id=26334516 - March 2021 (309
| comments)
| robertlagrant wrote:
| > it can also refactor Auth0's (and it's own) pricing to increase
| revenue even further.
|
| Yeah, about that. Auth0 is already struggling to compete with
| Firebase Auth, AWS Cognito, and even Azure AD B2C (at least on
| price, for that last one). Increasing the price further is a bad
| idea.
|
| Also, ory.sh is coming. If I were Salesforce, I'd be funding that
| to just commoditise auth.
| advaitruia wrote:
| Author of the article here. Feel free to AMA about the
| acquisition (or about SuperTokens)
| postit wrote:
| They OH auth0 was using mongo to store customers' data and wanted
| to fix that.
| Naac wrote:
| What are some open source self hosted alternatives to Okta and
| Auth0?
| arawde wrote:
| > Okta will issue shares to Auth0 shareholders at share price of
| $276.21, close to 20% less than the current share price (at the
| time of writing).
|
| The screenshot immediately under this statement shows an Okta
| share price of $226. Am I misunderstanding something?
| [deleted]
| [deleted]
| kweinber wrote:
| The deal had to be done at a certain time, which froze the
| value of the shares at the price. The shares were probably
| reserved for this purpose at that time.
| coreyja wrote:
| $276.21 - 20% = $220.968
|
| So not far off from $226
|
| $226 / $276.21 = 81.8%
|
| So its 18.2% to be exact
|
| Edit: Realized the quote/article says 20% LOWER. Which is
| backwards, and is likely what my parent comment is pointing out
| jiveturkey wrote:
| The screenshot did not properly show the price "at the time of
| writing". sloppy, that's all.
| pwlb wrote:
| Self-Sovereign Identity might replace major parts of the
| federated identity market within 5 years i expect. even Okta CEO
| admitted that self-sovereign identity will be the future. the
| major problem is that the decentralized nature of SSI, will
| remove the most part and profit of 3rd party tools, as it is
| easier and cheaper to have direct relations between services and
| users
| cwkoss wrote:
| > Auth0 is the most prominent alternative that customers consider
| when evaluating Okta. The acquisition of Auth0 eliminates that
| threat and grants Okta pricing power as a result.
|
| "Grants pricing power" is such a euphemistic phrase for
| "solidifying a monopoly will let them price gouge"
| xapata wrote:
| Or "monopolistic price gouging" is a dysphemism for having a
| stable business in a tough market. They need to make enough
| profit to avoid capital outflow.
| tsimionescu wrote:
| Buying a competitor is always a dubious move towards
| monopoly. If the ideal free market is supposed to have all
| sorts of advantages, then anything which reduces the ideal-
| ness of the actual market must be viewed as negative.
| oppositelock wrote:
| Luckily, we have alternatives, so their pricing shenanigans can
| only push people so far. For example, Keycloak is some self-
| hosted open source software which is a drop-in replacement for
| any Oauth2/OpenID Connect service. It doesn't get you a nice
| applications panel like Okta does, but it's a workable
| alternative. Given what I spend on Okta, prices doubling would
| put me on the fence, and tripling would move me to an
| alternative.
|
| I do use both - Okta for internal users, and Auth0 for customer
| accounts, and I'm bummed that the quick and easy (Auth0) is
| being subsumed by the stuffy enterprise company.
| BurningFrog wrote:
| The Economist response is that Okta just rewarded their
| competition with $6.5B.
|
| This is a serious incentive for anyone to launch a new company
| in the field.
| bsder wrote:
| I have been beating the drum for a straightforward hardware
| key-based identity system for 5-50 users here for _years_.
|
| And, yet, everything is still a pain in the ass.
|
| We were looking at Auth0 precisely because Okta was doing the
| enterprisy thing. Sigh.
| grinich wrote:
| Shameless plug - We are doing this at WorkOS. :)
|
| It's like Stripe for enterprise features, including SSO/SAML,
| Directory/SCIM, and more.
|
| https://workos.com/docs
| polote wrote:
| > Okta is built as a top down sales organisation whereas Auth0 is
| built with a developer first bottoms up acquisition strategy.
| This allows Okta to get the best of both worlds.
|
| Good luck with that. The CEO of Okta will have to be very very
| very smart to keep this atmosphere around Auth0. So easier to say
| that's it's not going to happen. When you are an enterprise
| company you don't buy a customer centric company to become them,
| you do the opposite. You make them become like you
| [deleted]
| suff wrote:
| To be fair it's not nearly as crazy a valuation as $26B for chat.
| nikolay wrote:
| Auth0 was actually no alternative given its pricing. I actually
| saw a lot of people moving to Firebase from Auth0.
| willeh wrote:
| Most importantly Auth0 was beating Okta on execution. Auth0 was
| leaner and would soon get to feature parity for both use cases.
| Without this deal they would slowly have lost ground to Auth0.
| distrill wrote:
| This seems to be so transparently the case, how is this
| behavior not considered anti competitive?
| WJW wrote:
| Almost any behavior by a company to outdo its competitors can
| be described as anti competitive, but not all forms are
| illegal. Straight from the wikipedia page:
|
| > Anti-competitive practices are commonly only deemed illegal
| when the practice results in a substantial dampening in
| competition, hence why for a firm to be punished for any form
| of anti-competitive behaviour they generally need to be a
| monopoly or a dominant firm in a duopoly or oligopoly who has
| significant influence over the market.
|
| Since there are many auth providers (ie
| https://en.wikipedia.org/wiki/List_of_OAuth_providers) in the
| market, the takeover of auth0 by okta is not a problem for
| "the market". It is therefore up to the shareholders of auth0
| to sell their shares or not and clearly they chose to cash
| out instead of gambling that they could continue to out-
| execute okta and their other competitors.
| traverseda wrote:
| > Almost any behavior by a company to outdo its competitors
| can be described as anti competitive
|
| What? What definition are you using for anti-competitive.
| What you're describing _is_ competition.
|
| Here's the wiki article listing examples of anti-
| competitive action: https://en.wikipedia.org/wiki/Anti-
| competitive_practices#Typ...
| andjd wrote:
| The list of companies that offer OAuth is not a list of
| competitors to the service AuthO provides. It's a confusion
| that the latter has encouraged to draft on the former's
| coattails.
| nicoburns wrote:
| I imagine the parent is questioning why the definition for
| "a substantial dampening in competition" is so strict. To
| me it seems that they are claiming that this clearly
| constitutes a substantial dampening in competition, and are
| thus questioning why it is not illegal.
| ethbr0 wrote:
| By that metric, wouldn't profitless growth-over-
| capitalizing also dampen competition?
|
| It's a tortured argument to say that SoftBank's
| investments are creating more competition or innovation.
| nicoburns wrote:
| Yes, indeed it would. I guess the difference is it's
| harder to be objective about whether something is over
| capitalized.
| nanis wrote:
| FTC's Anti-Trust guide is a useful source[1].
|
| Specifically, the "Mergers"[2] section outlines the cases
| in which government interference might be efficiency
| promoting.
|
| [1]: https://www.ftc.gov/tips-advice/competition-
| guidance/guide-a...
|
| [2]: https://www.ftc.gov/tips-advice/competition-
| guidance/guide-a...
| Klinky wrote:
| Buying a successful competitor is not "outdoing" the
| competitor, it's almost admitting defeat.
|
| While you could say there are other offerings, are they as
| mature? A big shark swimming in a sea of minnows is not a
| balanced/competitive market.
| WJW wrote:
| Did you see the list of competing auth providers? It's a
| stretch to call Facebook, Google, Amazon and Microsoft
| minnows.
| Klinky wrote:
| The assumption you're making is that they have mature
| offerings because they are big names. Facebook, Google,
| Amazon and Microsoft have excellent full-featured
| offerings in every sector they've ever dabbled in?
| They've never made a bad or neglected product?
|
| This is exactly the problem, the assumption that huge
| conglomerate juggernauts hoovering up or invading every
| sector is adequate or healthy competition.
|
| Also that list seems to be very iffy at listing actual
| competitors to the Auth0 product offering. Much of it
| looks like services that use OAuth integration for access
| to their proprietary platform, not necessarily a dev-
| focused blank canvas for SSO/CIAM integration within your
| own app. Many specificly list OIDC as No. The list
| doesn't even have Auth0 on it.
| davewritescode wrote:
| I'm not sure I agree. The one killer feature that Auth0 has the
| Okta doesn't is their built in lambdas and they've had it
| forever.
| mooreds wrote:
| Makes me wonder why Auth0's board of directors agreed to the
| sale.
| redisman wrote:
| I would guess the 3.5x valuation from last year.
| bsder wrote:
| SoftBank stupid money is gone.
| techrat wrote:
| "Cha-ching!"
|
| Business hasn't been about the long term for a while,
| especially if you're a startup. The goal is to gain
| recognition and sell at the first good chance you get...
| rinse, repeat.
|
| You only need to look at what happened to Sears and K-Mart to
| know that what people look for in value of a company is what
| you can sell off, not how well you can compete.
| outside1234 wrote:
| Stacks and stacks of guaranteed money?
| lmeyerov wrote:
| because unlikely to be a bigger buyer later, so sell now or
| chase ipo. likely vc-controlled, so less risky to get the
| (winning) liquidity now.
|
| once you hit a certain level, you run out of buyers, and thus
| lose much of your ability to sell at multiples over value...
| so effective price ceiling.
| mooreds wrote:
| > once you hit a certain level, you run out of buyers,
|
| There's always salesforce :).
|
| No, thank you for a cogent analysis; interesting to me how
| the incentives shift as you grow and how an IPO can be
| riskier than a sale.
| lmeyerov wrote:
| yep, good comparison! crm bought tableau for $15B+ and
| google was fine w/ Looker @ $2B, and data is a clear
| high-ceiling market.
|
| not a lot of buyers at that level, so as soon as > $1B,
| and bought for way more than 10X on revenue, so unclear
| if/when they'd see $6B again. capital is cheap right now
| too, and while interest rates are expected to stay low
| for 3+ yr, in reality no one knows as the current
| situation is confusing economists...
| woot482 wrote:
| If this was true and was indeed very little risk in getting
| there, they wouldn't have sold. Think about it.
| djrogers wrote:
| I work with a LOT of large enterprises, and I see Okta
| everywhere. Where I don't see Okta, I see Microsoft and Ping.
| I've never run across an enterprise using Auth0, so I was
| surprised to see this statement:
|
| >Auth0 is the most prominent alternative that customers consider
| when evaluating Okta.
|
| Is there a feature/vertical where Auth0 and Okta compete that
| isn't enterprise IDMS? Or was Auth0's market outside of the
| Fortune 500 space?
|
| * edit - OK, it seems clear from the responses that what I see
| Okta used for (employee/internal identity management) is not what
| Auth0 was focused on. That makes sense - thanks for all the
| answers!
| derekp7 wrote:
| The company I work for went with Auth0 for a new SAAS offering,
| partly because Auth0 kept beating Okta on price (at least for
| our use case).
| victor9000 wrote:
| With this acquisition, that won't be the case much longer.
| swagonomixxx wrote:
| Primarily startups. We've used Auth0 for the last 4 years and
| we've only ever had one outage.
| mooreds wrote:
| I would say that Okta was primarily IAM (identity and access
| management for your employees) and Auth0 was primarily CIAM
| (customer identity and access management).
|
| So I think they both were aiming at the same customers, just
| for different use cases.
| milesdyson_phd wrote:
| We were/are (Fortune 500) in the process of migrating from Ping
| to Auth0... Glad I'm not on the group that's been working on
| that for the past 1-2 years
| exikyut wrote:
| Interesting sentiment. What were the pain points? What was
| better about Ping?
|
| Your comment is an interesting contrast against
| https://news.ycombinator.com/item?id=26359752
| mimixco wrote:
| Startup here who went with Auth0 for our SaaS. It seemed very
| developer friendly and something we could (and did) on-board
| ourselves. It gave us a custom, federated identity system that
| could brand and integrate with our backend without getting into
| a big enterprise sales cycle. We're a small team.
| ucarion wrote:
| Okta and Auth0 have mostly been serving the opposite ends of
| enterprise login, with Okta starting to take on Auth0 (and not
| so much the other way around).
|
| Okta mostly handles being the "enterprise database of users +
| gateway to your enterprise apps", i.e. it's an identity
| provider (IdP). ActiveDirectory and PingIdentity are
| competitors here.
|
| Auth0 mostly handles the other end of the line: they help
| companies be "a thing you can log into using an IdP", i.e. they
| help companies be a service provider (SP). Custom SAML/OIDC
| implementations are the biggest competitors here. Okta has
| increasingly been competing with Auth0 in the space of SaaS SP
| solutions.
|
| So it's in the latter half -- service providers -- where the
| two compete. You may have been looking in the wrong place.
| Plus, not all companies are service providers, and many
| companies that are service providers roll their own
| implementation of the relevant protocols.
| wenbin wrote:
| Waiting for "I can build this over a weekend" comment on Hacker
| News :)
| redis_mlc wrote:
| I talked to one of the founders several years ago.
|
| An experienced programmer probably could but:
|
| - writing an app doesn't mean it's a business
|
| - Okta has thousands of partner integrations, with the
| development costs borne by the partners.
|
| Fun fact: Okta, an auth database company, did not have a DBA
| until around 200 employees. Then they ran into technical issues
| and started interviewing for one, but nobody was qualified to
| do the interviews. (They do have a DBA team now.)
| manishsharan wrote:
| since you asked for it :
| https://developers.redhat.com/blog/2017/01/05/spring-boot-an...
| moooo99 wrote:
| Honestly, properly configuring, maintaining and scaling
| Keycloak is an absolute pain in my experience. Keyclaok does
| not come close to the ease of use of Okta and Auth0 imho
| turtlebits wrote:
| Can you please elaborate on the issues you are seeing?
|
| I just got started, but so far my experience setting
| Keycloak up has been the best I've experienced for an open
| source project in a while. I was up and running within a
| few hours-
|
| Got a simple JS app working, and was able to secure all my
| existing services by integrating with my ingress
| controller.
| thinkharderdev wrote:
| Recently moved away from Keycloak (which I think overall
| is a great piece of software but was just a PITA for our
| use case) and my observations:
|
| * Zero-downtime deployments don't really work. They
| kinda-sorta do but it was too clunky for us to do it
| effectively during periods when we had significant
| traffic. Not generally an issue if you are just using
| out-of-the-box components but if you are deploying custom
| components (Storage providers, authenticators, etc) then
| it doesn't work that well.
|
| * It uses an in-memory distributed cache for
| authentication sessions so if your instance goes down (or
| you need to shut it down for a major version upgrade)
| then everyone is logged out. It also seems to have a lot
| of trouble scaling out to more than ~8 nodes. At the
| minimum you have to do a lot of tuning of infinispan
| parameters to get it to work at scale.
|
| * Configuration is kind of a pain because it has to be
| done through the UI. There is a REST API but it is really
| hard to work with if you want to do something like deploy
| a change to an authentication flow configuration. So
| forget about managing your configs in source control (and
| prepare for the inevitable issues that happen when
| configs aren't properly updated with deployment because
| someone fat-fingers something in the configuration UI).
|
| * There is a LOT of stuff that is hard-coded in the core
| Keycloak engine that makes customization impossible short
| of modifying the actual Keycloak source itself and
| running your own build (not recommended!).
|
| * One small thing that nonetheless drove me crazy is the
| Keycloak injects a JS snippet into rendered templates to
| munge the browser history and has no way for you to
| insert a nonce in the script tag, so setting up CSP
| headers was way harder than it should have been.
|
| All that said, it was more that Keycloak was not the
| right tool for our use case (an always-on user-facing
| identity provider) but if you just need a basic
| login/registration screen and are fine using Keycloak's
| built-in components (with maybe just some thumbing) then
| it works great.
| thesimon wrote:
| Spring Security is really pleasant to work with.
|
| Keycloak is also quite nice, but configuration is rather
| annoying at times.
|
| Should be workable.
| nailer wrote:
| Honestly, if you're doing AD, SAML, etc - sure go with Auth0.
|
| If you want oauth2 + OpenID connect, use a damn library. Auth0
| will make it more complicated not less.
| andybak wrote:
| I would do but I'm not even sure I understand what any of this
| does.
| akvadrako wrote:
| If somebody would write an Auth0 replacement over the weekend,
| that would be great.
|
| Coincidentally I was looking for a self-hosted auth solution
| today and I can say there isn't anything that's close to as
| easy to use as just paying for Auth0.
|
| Some decent one's I found where keyclock, glewlwyd and ory, but
| they where too heavy or complex. I ended up going for caddy-
| auth-portal, which doesn't even do user management yet.
| advaitruia wrote:
| What do you think about Supertokens.io?
|
| Granted its not as mature but its open source, easy to
| implement (decouples features based on your use case), really
| customizable frontend UI and great support (ping me anytime!)
| mooreds wrote:
| Would love your feedback on FusionAuth (full disclosure, I
| work there).
|
| Free to download and run (but not open source, if that
| matters to you): https://fusionauth.io/download/
|
| I don't know your exact use case but would be happy to chat.
| mooreds wrote:
| Thanks everyone for the feedback about the muddy message.
| I'll see what I can do to clear it up, now and later on the
| website.
|
| If you want the basic community edition (you can see the
| features here: https://fusionauth.io/pricing/editions/ by
| expanding the 'Full Feature Breakdown' table) and want to
| self host, you can download this free as in beer standalone
| executable: https://fusionauth.io/download/
|
| If you want us to host the basic community edition for you,
| you can purchase a single tenant instance managed by us:
| https://fusionauth.io/pricing/cloud/
|
| If you want premium features (LDAP connectivity, breached
| password detection, and others), you can buy a paid
| edition; some of these include support:
| https://fusionauth.io/pricing/editions/
|
| If you want us to host for you and you need the premium
| edition, you can buy both a license.
|
| Additionally, for some uses (if you resell FusionAuth to
| your customers, for instance) you will need to talk to us:
| https://fusionauth.io/license-faq/
|
| Wow, writing that makes it clear to me how unclear that is.
| I'll see if we can't simplify or make this clearer.
|
| Thanks again for your feedback!
| akvadrako wrote:
| I might consider something closed source but I find your
| offering quite confusing. Is the download a standalone auth
| server? I notice it isn't mentioned on the pricing page so
| I don't really get it. It would also depend what the
| minimum RAM requirements are.
| runako wrote:
| Not OP but I wouldn't consider using this because it
| doesn't say what you said "Free to download and run." The
| language on the site makes it look like a free trial of
| some sort.
| nightski wrote:
| As indicated by another commenter I found the product
| messaging/pricing really confusing. There's "Cloud",
| "Editions", "Reactor" with little way to see how the relate
| and it's not immediately obvious there is a self hosted
| version. This turned me off as I just saw $75/month for a
| development/test version (which isn't really the case).
|
| After diving in deeper the pricing calculator really
| cleared things up, but I think the menu structure and front
| page messaging could be vastly improved to help guide the
| user.
| AlbinoDrought wrote:
| We're using Ory Hydra and a modified version of Ory
| Oathkeeper in production, but our usecase might be a bit
| different (we already had a user database and auth system).
| Compared to implementing them from scratch, setup was simple
| and the end product is fantastic.
|
| We're looking at migrating to Ory Kratos eventually. It seems
| to offer the things we would've wanted from Auth0, but
| selfhosted. Granted, you're right - I'm sure it's much more
| complex to selfhost Kratos than to pay for Auth0.
| robertlagrant wrote:
| I'm extremely excited by ory. We're using some Auth0 and
| some AD B2C, but I'd love to move to ory and just run our
| own thing.
| alexeldeib wrote:
| How mature do you feel the Ory ecosystem is? Any major
| speedbumps?
| sebmellen wrote:
| Would love to know as well. Considering a switch from
| Cognito here.
| thinkharderdev wrote:
| We are using Ory Hydra now (but not any of the other
| components like Kratos, Oathkeeper, etc) and no real
| complaints so far. It is important to understand though
| the Hydra is just a component and not an out-of-the-box
| solution. You still have to implement your own user
| interface is you plan on doing OIDC login (and not just
| client_credentials for service authentication). Basically
| Hydra just takes a self-hosted login/registration/etc UI
| which you build yourself and wraps it in an OIDC
| provider. Which is great if you need to build an OIDC
| provider and want tight control over the user experience
| and user management (our use case) but don't want to
| implement all the fussy details of the OAuth2 protocol.
| nickysielicki wrote:
| The question isn't whether there's value here. They've got
| revenue and you can't dispute that.
|
| The question is whether they're worth 13x more than a valuation
| of 500 million dollars.
| cphoover wrote:
| When people say oh it has a $30 Billion addressable market... how
| do they come up with these numbers? Startup CEO types love to
| throw around these numbers but some time they seem wildly
| optimistic, and their methodology is rarely explained.
| malyk wrote:
| Could be as simple as "number of companies that need auth x
| number of employees of that company x average cost per seat for
| Okta/Auth0".
|
| Now, figuring out some of those numbers is harder. Okta
| simplest pricing is $2 per person per month, but to really us
| it you are looking at paying more like $15 a month. So, per
| user it's $180 a year. 30 billion / 180 = 166 million users. If
| average company size is 500, that's 330k companies, which is a
| lot.
|
| Anyway, those are just very quick back of the napkin numbers. I
| would guess they've done a little more work to come up with the
| number.
|
| (pls forgive any math errors/rounding!)
| pc86 wrote:
| Yeah these figures really are less to differentiate between
| the $33 billion and $34 billion markets, and more to
| differentiate between the $33 billion and $33 million
| markets. Just a way to get a rough idea of approximate size,
| as compared to other rough ideas of approximate size.
___________________________________________________________________
(page generated 2021-03-05 23:01 UTC)