Upgrade Office ASP.NET SSO to ASP.NET Core - why "Remove fallback code" (Office dialog)?

[jimbarrett33]

The recent upgrade of ASP.NET SSO to use ASP.NET Core removes the fallback code which pops up the Office dialog does the complete auth flow with redirect to Azure AD and back to the web app servers-side code and then calls MS Graph. Why?

The Pull Request states "Remove fallback code as it now requires a second app registration which is a bit complex to include in this sample at this time."

Question 1: why remove this fallback code? I know it's answered by the PR comment but the prior sample with .NET 4.5+ was great because it included ALL the code needed for an add-in to handle SSO and Auth. Anyone that is developing a robust add-in and according to Microsoft Recommendation "should not rely on SSO as your add-in's only method of authentication."

Question 2: why does "upgrading" to ASP.NET Core require a second app registration? This is not clear to me.

I've been following and using the prior sample code (it works perfectly) and was waiting for (and appreciate) an updated sample with ASP.NET Core but it's really not as usable without the auth fallback code.

Thanks!

(Also, since the Office Docs have been updated, the Azure AD setup instructions for the previous full working sample are no longer available.)

[samantharamon]

Thanks for reaching out with your questions, @jimbarrett33.

@davidchesnut would this be something you can assist with?

[davidchesnut]

Hi @jimbarrett33,

Yep, great question! We're working with the identity team to update these samples and be sure they are 100% correct from a security pattern perspective. When you use MSAL for fallback, you still need to get an access token to your REST API server (ASP.NET). This appeared that it might require 2 app registrations (one for SSO usage, and another for the MSAL usage.) But through more research we've learned you can use 1 combined app registration, and for MSAL you just need to add an SPA redirect URI.

I'm working to restore the fallback code (with new pattern) to these samples. It's just that the old fallback code was passing a token from the server to the client, which is not recommended. We want to be sure no one is using that pattern, thus we removed it until we could get to a correct pattern.

Thanks!
David

[jimbarrett33]

Hey @davidchesnut,

Thanks for the quick response! Great news that you are still working on the fallback pattern with a single app registration. I am in the process of choosing the best way to go for a new add-in (actually old add-in from pre-SaaS monetization).

I agree with the previous sample issue of returning the token to the client. I would just add that I don't think it's required to return the token to the client. Instead, just return success to the client, cache the token on the server, and the client can retry the API without the token. The API can still throw unauthorized if it can't find or refresh the token (the FilesController in the previous sample was "open" anyway, except it checked for a token first thing). I realize those last few sentences sound simple but requires a lot of stuff to be coded. Also, the previous sample was a little kludgy since it was hitting 2 different API endpoints for the same data (api/values, api/files), except each one requiring a different token type. Maybe there is no way around that.

Anyway, I'll be working with the new sample and parts of previous samples to see if I can get something to work. Problem is that I'm not an Auth or .NET Core expert so it's slightly muddied waters for me :). But I'll let you know if I find anything worthwhile.

I'll also watch here for when you come up with a solution.

Thanks again!
Jim