Microsoft Loop: onder de motorkap

Als nieuwsgierige technoloog hou ik ervan een kijkje te nemen onder de motorkap van nieuwe technologieën om te begrijpen hoe ze werken. Onlangs had ik de mogelijkheid om Microsoft Loop te verkennen, een krachtig hulpmiddel dat teams, inhoud en taken samenbrengt over tools en apparaten heen en dat gebouwd is op Microsoft Fluid.

Tijdens het verkennen van Microsoft Loop was ik benieuwd hoe de verschillende API’s met elkaar communiceren om de gegevens weer te geven die gebruikers op hun schermen zien. Door dieper in de onderliggende API’s te duiken, kon ik een beter begrip krijgen van hoe Microsoft Loop functioneert en de technologieën die het aandrijven. In dit artikel deel ik mijn bevindingen en geef ik inzicht in hoe Microsoft Loop API’s gebruikt om gegevens te beheren.

Authenticatie

Wanneer gebruikers zich authenticeren bij Microsoft Loop, vindt de authenticatie plaats tegen de Chapter 5 Fluid App met het ID a187e399-0c36-4b98-8f04-1edc167a0996 en met het bereik https://clients.config.office.net/.default openid profile offline_access, wat https://clients.config.office.net/ de doelgroep maakt in je JWT-token.

Om de veiligheid van het authenticatieproces te waarborgen, gebruikt Microsoft Loop de Authorization Code-flow met PKCE (Proof Key for Code Exchange). Dit is een robuust authenticatieproces dat helpt code-injectieaanvallen te voorkomen.

Als technologieliefhebber was ik nieuwsgierig naar het authenticatieproces dat door Microsoft Loop wordt gebruikt en besloot ik te proberen de authenticatiestroom na te bootsen om te zien of ik er een access token uit kon krijgen. Ik liep echter al snel tegen muren op, wat een bewijs is van de sterke beveiligingsmaatregelen die Microsoft heeft ingesteld.

Hoewel het frustrerend kan zijn om de authenticatiestroom niet te kunnen repliceren, is dit eigenlijk een goede zaak. Het betekent dat het authenticatieproces van Microsoft Loop goed in elkaar zit wat betreft beveiliging, en dat gebruikers erop kunnen vertrouwen dat hun gegevens beschermd zijn.

API’s

Omdat het authenticatiegedeelte er niet in slaagde mij een access token te bezorgen, nam ik het actieve access token uit mijn actieve Microsoft Loop-sessie. Dat is geen best practice, maar zoals ik al zei, dit is uitsluitend voor informatieve doeleinden. Met dit access token kon ik dus enkele endpoints uitvoeren voor werkruimten.

De Microsoft Loop-endpoints werken momenteel op Microsoft 365 substrate, dat een cruciale rol speelt bij het faciliteren van services die werken over verschillende applicaties, waaronder Exchange Online, SharePoint Online, Teams en andere. Je zou kunnen zeggen dat de Substrate dient als het besturingssysteem voor Microsoft Cloud.

Haal je loopcomponenten op

GET https://substrate.office.com/recommended/api/beta/loop/deltasync?loopComponents=true

Hier werd ik aangenaam verrast dat er een API is waarmee je alle loop-componenten kunt opvragen. Met deze API kreeg ik bijvoorbeeld alle werkruimten terug, evenals alle pagina’s die onder een bepaalde werkruimte vallen. Het mooie hier is dat je ook alle verwijderde pagina’s terugkrijgt met uiteraard de eigenschap “isDeleted” ingesteld op true.

Een werkruimte aanmaken

Het aanmaken van een werkruimte leek aanvankelijk vrij eenvoudig. Al snel vond ik een API die dit deed via een post-verzoek met een body. Maar het bleek niet het effect te hebben dat ik verwachtte, omdat mijn werkruimte niet te zijn aangemaakt.

Toen ik goed keek, bleek dat direct na het aanmaken van de werkruimte een andere API werd uitgevoerd naar een ontoegankelijke sitecollectie. Deze API gaf een lange body terug die de pagina beschreef in json-formaat. Ik merkte ook dat hierbij een fluid-sessie-ID en een container-ID worden gebruikt. De container-ID is iets dat moet overeenkomen met de container die je doorgeeft in de json van je pagina, terwijl de fluid-sessie-ID moet overeenkomen met de sessie-ID die momenteel actief is op de server.

POST https://substrate.office.com/speedway/v1.0/workspaceGroups

Body:

{
     "displayName":"qsdq",
     "isPersonal":false,
     "enabledWorkloads": ["SharePoint"],
     "groupType":"Workspace"
}

Een werkruimte hernoemen

Om een werkruimte te hernoemen is het proces vrij eenvoudig. Er moet een PATCH-verzoek worden gedaan naar een specifieke URL, met de nieuwe titel opgegeven in de verzoekbody. Opmerkelijk is dat de URL een unieke identifier bevat, die bestaat uit een prefix (OID) gevolgd door twee afzonderlijke GUIDs, gescheiden door een @-symbool.

PATCH https://substrate.office.com/speedway/v1.0/workspaceGroups('OID:GUID@GUID')

Een werkruimte verwijderen

Een werkruimte verwijderen is ook vrij eenvoudig, door een DELETE te doen naar dezelfde API die je gebruikt om een werkruimte te hernoemen.

DELETE https://substrate.office.com/speedway/v1.0/workspaceGroups('OID:GUID@GUID')

Conclusie

Concluderend, hoewel het verleidelijk kan zijn om niet-officiële API’s te verkennen en ermee te experimenteren om een dieper begrip te krijgen van nieuwe technologieën zoals Microsoft Loop, is het belangrijk voorzichtigheid te betrachten. De API’s die in dit artikel worden besproken, mogen niet worden gebruikt om processen te automatiseren, omdat dit beveiligingsrisico’s kan opleveren en tot onverwacht gedrag kan leiden. In plaats daarvan is het aan te raden te wachten tot de officiële documentatie wordt uitgebracht voordat je probeert taken met API’s te automatiseren.

De API’s die momenteel worden gebruikt in de openbare preview kunnen een indicatie geven van de richting die de officiële API’s in de toekomst zullen gaan.

Al met al is de werking onder de motorkap van de openbare preview van Microsoft Loop goed in elkaar gezet en is er nagedacht over hoe bepaalde dingen werken. Het aanmaken van een werkruimte is vrij complex en ik hoop dat dit eenvoudiger kan zodra de officiële API’s beschikbaar zijn.