| I totally get the benefits, the part I'm struggling with is the real-world details. Like, the amount of effort it would be to put in application logic in order to determine attributes that would then be put on to the profile would be more than that which would be required to just have auth native in the code. Then there's the problem of keeping those attributes in sync with the application as things change. Then there's the problem of debugging when things go wrong - instead of being able to inspect the application state and determine the issue, now I have two places and different processes for issue resolution. I'm not talking about this in a hypothetical sense - I've tried this before. All sort of declarative rule based systems, and integration with Auth0 with attributes stored as part of the Auth0 profile, etc... After doing it and balancing the benefits, I've found that having well-architected code base with auth as a separate concern, but embedded within the native code (as a separate class/service/module/etc... is more effective and less work with better performance characteristics. Obviously this doesn't apply to every situation, I can think of several scenarios where third-part auth would work very well, I just don't run into them a lot. |