3 ms·

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 pro

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.

mooreds 6y ago
> 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.