1

I have a problem with making the Microsoft Account authentication working without the identity being stored in the database. This is all done in the latest VS 2017 install with the latest core 2.0 release. I followed this guide and managed to get it to work. The issue is that the guide assumes that the identity will be added to the database used by the application. This is because the sample uses:

var info = await _signInManager.GetExternalLoginInfoAsync(await _userManager.GetUserIdAsync(user));

and in the Startup.cs: 

services.AddIdentity<ApplicationUser, IdentityRole>().AddEntityFrameworkStores<ApplicationDbContext>().AddDefaultTokenProviders();

This is something I would like to avoid. My goal is to authenticate using the MS account and Authorize using the provided Claims (Claims-Based Authorization) but without the entire database structure from the sample being required.

I've struggled with this for some time now. I've tried to implement a cookie storage (even though the MS Account has one of it's own as far as I understand) for user login like it's done Here by removing the EF code that adds new data into the existing login from the database and adding the Signin call in the callback method from the sample. The User object at the callback point ( in OnGetCallbackAsync ) has all of the claims I need fetched from the Microsoft Account. When the redirect happens however the User object is empty (no claims, not logged in).

I would like to ask: what is the appropriate approach here? My understanding was that the MS account login already sets up a cookie so the removal of the code contacting the DB should have been enough; is this not correct? If so what steps do I need to authenticate the user in a manner described above?

I very much appreciate your help on this.

SpaceHedgehog
  • 41
  • 6
  • You'll need to persist the identity data somewhere in order to assign roles/claims. You could override the usermanager and store this in memory if you are against db/disk storage for some reason. Maybe add some context behind your decision why not to store in a db. – Chris Pickford Sep 05 '17 at 15:25
  • I do not have any intent to modify the users access rights outside of the Microsoft Account. In my mind the appropriate approach is to log into the account, persist the Claims in a cookie that expires in a couple of hours. No database access should be required (and honestly I don't want to add the Identity tables to the database just to achieve this if I can). I have nothing against disk storage as long as it's in the form of an aforementioned cookies. – SpaceHedgehog Sep 05 '17 at 15:30
  • You understand that cookies are stored under the client's browser, and doing so would mean a user could in theory assign claims/roles to themselves? – Chris Pickford Sep 05 '17 at 15:33
  • Isn't the User object available in the controllers stored entirely in the cookies no matter what Authentication you choose? For example the link from the original post pointing to the Cookie based authentication. SignInAsync creates a cookie from a provided principal. Wouldn't a user be able to modify that too if this was the case? Surely the cookies are encrypted and have some sort of integrity checks to stop tinkering. My goal is to use the normal Cookie mechanism as described in the tutorial but pass in the Principal obtained from the Microsoft account as the parameter of SignInAsync. – SpaceHedgehog Sep 05 '17 at 15:50

0 Answers0