Also is it just me, or is customer privacy just not a selling point? I see a section on compliance (e.g. protect yourself from consumer privacy regulations), but no marketing related to how FusionAuth helps protect your customer’s privacy.
It’s more of “we’ll protect you from your users” rather than “we’ll help you protect your users”. Which is disheartening.
That is covered under the "protect your company from data breaches" which also protects the customer. This is outlined elsewhere (for instance: https://fusionauth.io/learn/expert-advice/identity-basics/ou... ) but it could be mentioned here. I'll make a note to update it.
BTW this guide uses FusionAuth as an example, but the benefits of using an OAuth server apply no matter which kind you use.
Thanks for your response, and for the link. I believe in my parent comment I was conflating your article and the FusionAuth site as a whole. The best way to protect customer data is to not store it in the first place. For some use cases, federated identity can be perfect for this because you are explicitly delegating the storage of many (most) forms of PII to an external provider — usually one of the user’s choosing. Now the problem becomes one of implementing authorization (i.e. an authorization server or security token service) directly on top of federated IdPs.
By the way, I appreciate your humility in your response. It reminds me that I need to do more of that.
> I was conflating your article and the FusionAuth site as a whole
No worries! Our entire expert advice section is really aimed at elevating the conversation around auth, not selling FusionAuth. That's the goal.
> The best way to protect customer data is to not store it in the first place.
100% agree, outsource it! Some of our customers outsource everything to existing third party providers; they just want FusionAuth's APIs to manage users, permissions and other info, but federate all authentication. Other people want to use FusionAuth as their system of record for users; in that case they are outsourcing to a specialized vendor (there are others, of course!) to not worry about their identity.
> Now the problem becomes one of implementing authorization
And, as you mention in a sibling comment, that is certainly going to become more tangled up in business logic.
> By the way, I appreciate your humility in your response.
Ah, thank you very much! Always something more to learn, appreciate your insights.
It seems strange to publish a “modern guide to OAuth” without at least a nod to OpenID connect. Disclaimer: skimmed the overview. Currently reading the whole thing.
Yes, I said the same thing to my co-author. He talks to a ton of customers and said that in his experience most people don't talk about OIDC separately from OAuth, and that they conflate the two.
Most OAuth servers that someone is going to consider as an auth system (authentication, authorization, user management) are going to include OIDC.
Oh that’s interesting. This is purely anecdotal evidence with small n, but:
1) I concur that Oauth2 and OIDC are often conflated, and then contrasted to SAML and single-sign on (also conflated).
2) No one wants to manage identity (federation by default), but almost everyone wants to manage authorization. This makes sense, since authorization is strongly related to business logic.
> This makes sense, since authorization is strongly related to business logic.
Definitely. I'd say you could further break authorization into two components:
* what permissions/roles a user should have
* what those permissions/roles can do in an application
The former is somewhat amenable to being centralized in a user management application. The latter is always going to be application dependent and should be handled inside an application's business logic (perhaps abstracted to a central component there).
Are you asking about FusionAuth? There are some comparisons to Okta and Auth0 on the website. I'm not sure about acmelogin, though, that's the first I've heard of it.
In comparison to Auth0, I'd say our biggest difference is our pricing model (they are cheaper if you are hosting with them, until they get more expensive), the amount of features you get at $0 (especially SAML and OIDC connections), and the ability to self host. We also hear that our multi-tenant support is better.
With respect to Okta's CIAM solution, I would say that our pricing is smoother (they just started offering 15k users for $0, then at 15001, it is $4000/month), we are more developer friendly (all API driven, more consistent APIs), and our support is more responsive.
But all of these solutions have a free or low cost tier and I wouldn't want to make any decisions as fundamental as my user storage system without kicking the tires and doing a POC.
It’s more of “we’ll protect you from your users” rather than “we’ll help you protect your users”. Which is disheartening.