In our multi tenant SaaS software application we intended to use Microsoft Identity Platform (Azure AD) for user authentication and providing the claims for authorization within the application. We are facing a lot of difficulties managing and getting the correct claims throughout the stack and are now considering providing our own identity and web tokens (through a library like Microsoft.AspNetCore.Identity).

This means we would still rely on Azure AD for the authentication, but then use our own (synchronised) identities to manage application roles, permissions, etc and store these in the application database.

Q: What are the security risks we will be exposed to when we provide our own identity rather than use a service for these, keeping in mind we would still use a service for the authentication?


But, the biggest issue stems from not leaving the identity up to the experts that have studied the numerous standards and security policies. Sure, you could learn all of it yourself and implement it securely, but it will be time and resource consuming. That's just the tradeoff you have to make (as it is with many SaaS solutions).

If you're storing the identities in your application database, you open the door to a hacked application leading to hacked identities. Versus if it were separate, you could have better encapsulation there. Bad practices in storing passwords or passing them over unencrypted protocols could lead to stolen identities.

*I'm biased as I work for an Identity Provider, but I've tried to be completely open and honest here.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.