3
points
arekkas
Joined 719 karma
- We do have all edge cases brought to us solved in terms of account linking and the recent changes further improve the user experience in these scenarios. There are many credential types around these days from passkeys to OTP codes to passwords and OIDC. The biggest challenge is always ensuring the flows are secure which is the hardest part in our view.
ps: I find it a tad frustrating that on every Ory post FusionAuth is shilling in the comments, even if the comment is tangential but clearly intended (through links and name dropping) to draw attention away. It would be much better if FusionAuth focused on releasing open source themselves and truly contributed back to the security community instead.
- The flow is essentially what you see in the small video on the docs page and can be set up in the Ory Network Console with a few clicks. I agree though that the docs here are a bit thin.
Pricing wise this is available on the Scale tier currently dubbed as "Enterprise SSO" although "B2B Organizations" probably would be more correct: https://www.ory.sh/pricing/
There are no limits to how many organizations you can have.
Regarding MFA - the MFA enforcement typically is the responsibility of the IDP the company owns. So for example dean@companyA.com use Okta and they enforce 2FA for their users. anna@companyB.com use OneLogin and they do not enforce MFA.
- We have this feature and it is called B2B SSO: https://www.ory.sh/docs/kratos/organizations
- Yes, this is definitely true. However, there are use cases and companies who rely on SMS based two-factor:
- Using SMS for phone verification
- Using SMS for mobile login (think dating apps for example)
- Using SMS for two-factor where other factors are not available / convenient (often in emerging markets)
SIM Swap Attack, SIM Port Hacking are all real, but as always in security it comes down to your threat model to decide what's acceptable risk and what isn't.
Hope this makes sense (maintainer here).
- ORY | Munich, Germany | On Site | FULLTIME
We build stuff for an emerging cloud infrastructure. It’s security, zero trust, hardcore bullet proof engineering. It’s Golang, K8S, React, Hashicorp etc. - no more buzzwords! Just drop us a short introductory email to jobs@ory.sh. We believe that great engineering deserves to be paid accordingly.
Our open positions (all full-time in Munich, Germany):
Software Engineer / Go; Software Engineer / React; Software Engineer / SRE
Our GitHub: https://github.com/ory
Our Website: https://ory.sh
- 1 point
- 2 points
- Couldn't agree more with these points. I'd like to point out that
> It isn't a bad idea to read and learn from the OAuth 2 spec in order to make your own auth services
has actually lead to quite horrible auth systems. I've seen bad stuff in large enterprises due to this ("we're smarter, we'll solve it for our use case" -> "Oops, we didn't think about session replay").
I recommend OAuth2 for complex systems with many involved parties and clients. There it can really reduce complexity. For normal apps with maybe 1-2 consumers, cookie-based security is secure and good enough!
- Why are developers of popular database solutions so reluctant to write secure-by-design software. You would guess that some basic form of authentication should be implemented in any internet-facing service. But here we are, after the MongoDB fiasko, still left with thousands of vulnerable services because someone didn't bother to implement basic auth.
- Let's break this down.
> I'm convinced that unit tests don't usually find bugs.
They don't, they test whether or not the API contract the developer had in mind is still valid or not.
> IMO, most bugs are edge cases that were an oversight in the design. If the dev didn't handle the case in code they're not going to know to test for it.
You don't write test to find bugs (in 98% of cases), but you can write tests for bugs found.
> Fuzzing is a much better approach.
If you're writing an I/O intense thing, such as a JSON parser, then yes. For 80% which is CRUD, probably not.
> The project with high code coverage is basically shit and has so many bugs that we regularly cull anything marked less than "medium" severity as "not worth fixing". This project was written by a team that loves "patterns", so you can find all sorts of gems like Aspect Based Programming, CQRS, N-tier, etc. well mixed into a featureless grey Java EE goo. We get so many bug reports that its someones job to go through them.
You are blaming tests for bad design choices. With the patterns raised unit tests only get you so far, integration tests are what help you prevent bad deployments.
> The other project with no tests is a dream to work on. Not a single file over a few hundreds lines, everything linted and well documented. Almost no methods that don't fit on the screen, no recursion. No bullshit "layering" or "patterns". I can't remember the last time we had a bug report, since our monitoring picks up any exception client and server side. Every bug I've worked on was identified by our monitoring and fixed before anyone noticed.
So how many exceptions were raised due to bad deploys? Core review only gets you so far.
> If your developers are great then tests would hardly fail and be fairly useless, and if they're terrible tests don't save you.
Failing tests don't have to do with devs being "great" or not. Developers must have the capability of quickly testing the system without manual work, in order to be more effective and ship new features faster. If the tests are one-sided (only unit tests, only integration tests), then this will get you only so far, but it still get's you that far.
Don't abandon good development practices only because you saw a terrible Java EE application.
- 5 points
- It's really nice that we see more and more awareness for Zero Trust and specifically Google's BeyondCorp whitepaper. If you're looking to experiment with this model yourself, check out the following open source projects. While they might not implement everything in Google's BeyondCorp paper yet, they are pretty close to the full thing, and address many issues raised in the comments.
-> OAuth2 Authorization Server https://github.com/ory/hydra
-> Identity & Access Proxy (early access): https://github.com/ory/oathkeeper
If you have questions don't hesitate to ask.
- Literally the comment above:
> On-chain scaling is not sustainable. If you want to handle as many transaction as for example Visa, you would need 1 GB blocks every 10 minutes, which would make the whole blockchain heavily centralized because regular users won't be able to host full nodes to validate payments.
I‘ve felt the same as you many times over, and I have had bad experiences along the way. In the end it still feels that it was worth it. I get to own and work on things I enjoy.
For me, taking on VC capital was the stepping stone for today‘s success, but that was necessary due to the complexity of IAM and the system criticality it has (single point of failure). It’s essentially impossible to do something like Ory without outside money.
Generally speaking I felt that libraries are harder to monetize than APIs, but looking at your website you already have a service! Monetize the service, keep the OSS free (but maybe don’t make everything OSS).
One thing we open source people are bad at is valuing our own work (because we publish it for free). But experience has shown me that people are willing to pay if the service is valuable enough even if you can get it for free otherwise. So many companies spend 100k, 200k, 2M ln bad software. Why should they not spend 100k with your good product?
If you don’t want to have a boss and don’t want to live on someone else’s terms (yes VCs, customers and others tell you what you SHOULD do, but you can still do it differently and they will applaud you when it works), keep doing what you‘re doing and don‘t be afraid to ask MORE money for it, not less.
To get to 250k to support yourself, you will have to sell a lot of subscriptions. So maybe the value lies elsewhere? Integrations, customization? Number of form fills? Bot protection? Your customers/adopters typically tell you what‘s valuable - but don’t do it all for free!
Looking at your repo it has some traction, but you probably need to build it up a bit more with marketing (wether that‘s cool new tech, or just posting it in the right places is up to you). If you have a couple of companies that are interested in using it and need support, sell them support for 10k, 20k, 30k a year and learn what they need, build it, and sell it to them again. Why build stuff for free if the customer is making money with it?
I believe you can do this!
If you are bootstrapped, don‘t try to mimic typeform subscriptions will only work with sufficient capital and a lot of upselling. Self-service subscription selling is hell and requires huge infra and marketing budgets. Try to find a couple of customers that pay you well and expand from there.