Microsoft Teams : Config Tab SSO First Time Consent Challenge

Microsoft Teams : Config Tab SSO First Time Consent Challenge

On SSO

 In this post I'll walk you through a challenge I've faced which might break your Microsoft Teams app acquisition flow specially if you are building an App Source Mutli-tenant application. Microsoft Teams offers a basic SSO which is easy to configure if you follow the guideline and steps explained in the below article:

https://docs.microsoft.com/en-us/microsoftteams/platform/tabs/how-to/authentication/auth-aad-sso 

So where is the problem, I can name a few but I would focus on one specific use case when you add the tab first time, the Azure AD app need to capture user or admin consent so it would:

1. Prompt that you need to trust the app
2. When you click continue a consent dialog will popup and you would be able to consent or cancel 
3. The entire Teams tab will be refreshed and when you try to get authenticate the current user everything works as expected.

I know so far I didn't list any problems, the corner case if your Tab configuration screen requires some sort of SSO to retrieve some information form your protected APIs and save the tab settings before rendering the tab.

In this case the step #3 will force your Microsoft Teams tab to refresh and you would need to restart adding the tab once again, in the second time this would work perfectly, see the screen capture below to get a clear idea of the experience:

Not a big issue to be honest but If you are building an multi-tenant app people might think there is something wrong with the app. If you dig deeper you can see that Authentication is handled by the Parent windows which is Microsoft Teams app itself

So in short we don't have much control of how the parent would handle the authentication, my first thought was to ditch the whole ms-teams.js library and do the authentication on my own ! which is not recommended. I noticed that there is a silent parameter in the AuthRequest, if I pass it  getAuthToken will fail and won't prompt the user to consent. 

The solution I end up using is to implement the consent flow on my own so the built-in authentication mechanism won't refresh the whole tab and won't break the acquisition journey and if the silent authentication is a success that means the user/admin has already consented to the required permissions 

SharePoint Online: Use SPO as headless CMS for Public Facing websites

SharePoint Online: Use SPO as headless CMS for Public Facing websites

On SharePoint

Yes, the title is correct. It's not a typo. SharePoint online and public facing websites in the same sentence.

Some of you would wonder, is that an old concept, old post, we are in 2020 and SharePoint online doesn't offer the public facing site collection anymore. Have I gone mad !?

I was planning to write down this blog post for over four years now and every single time I really pass the buck on that one.

If you are/were a SharePointer part of your work experience was somehow focused towards customer experience not employee experience.  For me it was  the main focus as I used to to work more on building public facing solutions/experiences using On-premises versions of SharePoint 2010/2013 rather than intranets and extranets.

Note:  if you are looking for a rich experience this wouldn't definitely be the right path, also the intention of this post is just to go through a recent personal experience for an idea I had for almost over 5 years ago.

Don't get me wrong , Intranets/extranets were always integral part of our offerings back then but as more spent was poured towards brand identity and public facing experiences we get more public facing websites.

Implementing a complex and innovative designs on top of SharePoint was always challenging , the amount of time spent to make a SharePoint public facing sites using custom Master pages is enormous.  Moreover, it was hard to maintain and the most challenging task used to fit the custom UI on top of SharePoint as the poor UI developer tries to get a fully working standalone HTML/CSS works fine within the SharePoint realm !

To avoid some of these complications, we always tried to separate the concerns and use SharePoint site collection for publishing and use cross site publishing features to leverage content from multiple authors. 

But when it comes to the UI  concern separations and loose coupling wasn't that obvious. We have always used a customer master page. I remember in rare occasions building ASP.NET web applications that uses SharePoint APIs to get the required content and it had worked very well for us but it comes with the following caveats :

• Maintenance overhead  : Additional Website, where to host, make sure it's redundant and can scale up etc...
• losing WYSIWYG aspect or in some cases making WYSIWYG more difficult as content editors need to lunch the standalone web app to view what the site will look like instead of just clikcing on a publish button. 
• Can't use OTB components, which is very useful specially in search scenarios.
• Missing out on some SharePoint features specially around analytics (but most of our public facing websites were using a different analytics solution)

This is not a the first time I blog about the loosely coupled approach. I've shared almost the same approach but for a loosely coupled intranet back in 2016 and I've built it even using NodeJS and present it in Perth Office 365 Saturday back in May 2016.

If you want to view my previous post at http://www.sharepointtweaks.com/2016/01/officedev-the-new-intranet-loosely-coupled-approach.html 

So the approach is pretty the same but we would use application permission to allow anonymous users to use the APIs without promot them to be challenged via login page and get id and access token in the same manner that we would do in an intranet scenario, in a nutshell it will look the below:

Couple of things to note here:

1. Application permission is not enabled for every single endpoint
2. API access to SharePoint would be via Site.Read.All and Site.ReadWrite.All scopes which still in preview and doesn't allow you to limit access to a particular site collection.
3. Performance is not going to be great that's why I highly recommend using any kind of caching to make it less expensive for the API to return the content required by your client (SPA, web application or mobile native client)

It would be interesting to see if scopes can be limited to specific site collection also you can use this in conjunction with other delegated permission to fulfill different scenarios for your proxy API