I'm mid-way through a task to migrate a legacy .NET MVC app to use Single Sign On (SSO) to make integration with a to-be-developed mobile app possible. I'm planning on using Azure AD B2C to facilitate this and based on my research, I need to use custom policies to achieve the required functionality.
Work on this migration is proceeding very slowly. I'm finding the custom policy XML very clunky to work with. It's going to take quite some time to achieve parity with the existing system given the current velocity. I'm wondering whether it would be wise to sidestep a lot of the migration headaches by using the Microsoft Graph API in place of custom policies.
Take registration for example. It appears common to redirect the user to a SignUp.xml custom policy (or the integrated SignUpOrSignIn.xml) to handle adding the user record in the AD B2C data store. Part of this policy would involve calling a REST API to create a corresponding record for this user in the app's database (stores email settings and such). Instead of using these custom policies, my plan would be to instead take the existing registration process and simply add a step which creates the user record on the B2C side using the Microsoft Graph API.
It appears like most things I need may be achieved using the Microsoft Graph API. Things I'd need that I can see are not available are:
- logging in to a user account and;
- sending verification emails
Are there any other common authentication-related tasks I'm likely to need that couldn't be achieved using the Graph API?
As far as downsides, the fact I'd be handling user passwords (even if it was just to create the user and nothing else) is an obvious concern, but perhaps acceptable. The main thing I'm after is a simple SSO solution that generates secure access tokens (incl. handling reset tokens, etc). I hope then, that this could be a feasible option.