Hoe werkt de WebExtensions API binnen browserextensies?

De WebExtensions API biedt een krachtige en gestructureerde manier om browserextensies te ontwikkelen die functioneren binnen moderne browsers. Deze API is enkel toegankelijk vanuit JavaScript-code die binnen de extensie zelf draait en niet vanuit gewone webpagina’s, waardoor ontwikkelaars extra functionaliteit kunnen toevoegen die buiten het bereik van standaard webscripts ligt.

Centraal binnen de WebExtensions API staat het globale chrome-object (of browser voor compatibiliteit), dat meerdere namespaces bevat om verschillende functionaliteiten logisch te organiseren. Zo bevat chrome.storage methoden om gegevens op te slaan, en chrome.tabs functies om browsertabbladen te beheren. Dit modulaire ontwerp maakt het eenvoudiger om gerichte taken uit te voeren zonder het overzicht te verliezen.

Een eenvoudige maar illustratieve methode binnen deze API is chrome.runtime.openOptionsPage(). Hiermee kan programmatic een nieuwe tab geopend worden die verwijst naar de optiespagina van de extensie. Dit is mogelijk doordat de optiespagina in de manifestfile van de extensie geregistreerd staat. Op deze manier wordt een naadloze gebruikerservaring gecreëerd waarbij gebruikers direct via de interface van de extensie instellingen kunnen wijzigen.

Daarnaast is het implementeren van een welkombericht bij de eerste installatie van de extensie een nuttige praktijk. Dit kan door in de optiespagina een controle uit te voeren op een specifieke queryparameter, bijvoorbeeld ?welcome, die vervolgens een boodschap toont. Het openen van deze pagina gebeurt via een achtergrondscript dat luistert naar de installatiegebeurtenis (chrome.runtime.onInstalled). Als de extensie geïnstalleerd wordt, wordt er een nieuw tabblad geopend met de URL naar de optiespagina inclusief de welkomparameter. Zo krijgen gebruikers direct na installatie een introductie aangeboden.

Een andere belangrijke functionaliteit betreft het conditioneel laden van content scripts. In plaats van dat het content script op elke pagina automatisch rendert, kan dit uitgesteld worden totdat een gebruiker expliciet een actie uitvoert, zoals het klikken op een knop in de popup. Dit vereist het toevoegen van de activeTab permissie in de manifest, die tijdelijk uitgebreide toegang geeft tot het actieve tabblad na een gebruikershandeling. Via het popupscript kan een bericht gestuurd worden naar het content script dat dan pas de interface-elementen in de pagina injecteert. Deze berichtgestuurde architectuur draagt bij aan betere prestaties en verhoogt de controle over wanneer en waar scripts worden uitgevoerd.

De architectuur van browserextensies is complex en omvat verschillende componenten die samenwerken: achtergrondscripts die op de achtergrond draaien, content scripts die in webpagina’s actief zijn, popups die via de browser UI toegankelijk zijn, en optiespagina’s waar instellingen worden beheerd. De WebExtensions API maakt het mogelijk om deze elementen op een gestructureerde wijze te laten communiceren en coördineren, waarbij elke component zijn eigen verantwoordelijkheden heeft.

Naast het functionele aspect is het belangrijk te begrijpen dat extensies een uitgebreid systeem beheren dat over meerdere vensters en tabbladen loopt. Content scripts kunnen bijvoorbeeld op verschillende pagina’s tegelijkertijd actief zijn en communiceren via multiplexkanalen. Bovendien moet versiebeheer zorgvuldig worden toegepast om bij updates van extensies de juiste functionaliteit te waarborgen zonder conflicten.

De gebruikersinterfaces van extensies zijn webpagina’s op zich—popuppagina’s, optiespagina’s en content scripts—die via standaard webtechnologieën worden opgebouwd, maar met toegang tot unieke browserfuncties. Daarnaast integreren extensies ook direct met de browser zelf, zoals via sneltoetsen, notificaties en URL-balkinteracties. Dit zorgt ervoor dat extensies niet alleen visueel aansluiten bij de browser, maar ook functioneel een verlengstuk ervan zijn.

Belangrijk is te beseffen dat het werken met de WebExtensions API niet slechts gaat om het aanroepen van enkele methoden, maar om het ontwerpen van een coherent systeem dat verschillende scripts en pagina’s samenbrengt. Elk deel speelt een rol in de totale architectuur van de extensie, waarbij communicatie, permissies en levenscyclusevents het fundament vormen waarop complexere functionaliteit kan worden gebouwd.

Voor een diepgaand begrip is het daarnaast essentieel inzicht te hebben in de manifestfile van een extensie. Deze JSON-bestand bepaalt welke permissies worden toegekend, welke scripts en pagina’s geladen worden, en hoe de gebruikersinterface is opgebouwd. Het is het startpunt en de configuratiebasis voor het gehele extensiegedrag.

De besturing van content scripts via gebruikersacties en het dynamisch openen van pagina’s via API-methoden illustreren slechts een fractie van wat mogelijk is met de WebExtensions API. Het opent de deur naar het bouwen van krachtige, interactieve extensies die naadloos in de browseromgeving functioneren, terwijl ze tegelijkertijd de veiligheid en privacy van gebruikers respecteren door strikte scheiding tussen extensiecode en webcontent.

Wat zijn Extension UIs en hoe functioneren ze binnen browsers?

Extension UIs zijn speciale browsercontainers die volledig worden beheerd door een extensie. Deze containers laden uitsluitend managed pages, dat wil zeggen pagina’s die door de extensie zelf worden bediend. Browsers stellen strikte regels aan wanneer en hoe deze UIs verschijnen, en ze bestaan in verschillende vormen die elk hun eigen eigenschappen en beperkingen hebben. De popup UI opent bijvoorbeeld tijdelijk wanneer een gebruiker op het extensie-icoon in de toolbar klikt en sluit automatisch zodra het focus verliest. Dit betekent dat de gebruiker niet tegelijkertijd met andere browserinhoud in hetzelfde venster kan interacteren terwijl de popup open is. Daarentegen is de options UI toegankelijk via browsergestuurde menu’s en kan zij als een aparte tab of als een overlay binnen de browser worden weergegeven. De side panel UI is een persistent en aanpasbaar paneel dat naast de hoofdinhoud blijft staan zonder navigatie te verstoren en dat dynamisch kan reageren op de actieve tab. Devtools pagina’s integreren diepgaand met de ontwikkelaarstools van de browser en zijn alleen actief zolang die tools geopend blijven.

Managed pages zijn een fundamenteel onderdeel van extension UIs. Dit zijn pagina’s die worden geserveerd door de extensie via een speciale browser-URL, waardoor zij speciale toegang hebben tot WebExtension APIs die gewone webpagina’s niet krijgen. Deze pagina’s zijn toegankelijk via URL’s die beginnen met een extensie-specifiek protocol, bijvoorbeeld chrome-extension://. Hoewel deze pagina’s meestal in aparte tabbladen kunnen verschijnen, worden ze voornamelijk geladen binnen de genoemde extensie-specifieke containers. Een belangrijk aspect is dat deze managed pages niet door gewone webpagina’s mogen worden geopend. Als een webpagina probeert om een extensie-URL te openen, zal de browser dit blokkeren vanwege veiligheidsredenen. Dit voorkomt misbruik waarbij webpagina’s gebruikers zouden kunnen hinderen door ongewenste tabs te openen. Alleen de extensie zelf kan via expliciete permissies en methodes zoals chrome.tabs.create() nieuwe tabs openen met extensie-inhoud.

De popup UI fungeert als een tijdelijk, zwevend venster zonder standaard browseronderdelen zoals de URL-balk. Het opent bij een gebruikersactie en sluit wanneer de gebruiker buiten de popup klikt of deze verliest van focus. De popup wordt geconfigureerd via de action.default_popup-parameter in het manifest, en als deze niet is ingesteld, zal een klik op het toolbar-icoon een event triggeren dat programmatisch kan worden afgehandeld. De grootte van de popup wordt bepaald door de inhoud, maar browsers hanteren verschillende limieten: Chrome kent geen maximale grootte toe, terwijl Firefox bijvoorbeeld de popup beperkt tot 800x600 pixels. Hierdoor is het aan te raden om popups responsief te ontwerpen of een vaste, compacte grootte te hanteren om inconsistenties tussen browsers te vermijden. Binnen de popup wordt navigatie tussen extensiepagina’s technisch niet verboden, maar het wordt afgeraden omdat gebruikers geen URL-balk of navigatieknoppen tot hun beschikking hebben, wat kan leiden tot een verwarrende gebruikerservaring.

De popup UI kan op verschillende manieren worden geopend: via het klikken op het toolbar-icoon, het indrukken van een vooraf ingestelde sneltoets of programmatisch door de extensie na een geldige gebruikersinteractie. Sluiten kan gebeuren door het opnieuw klikken op het icoon, klikken buiten de popup binnen hetzelfde browservenster, het aanroepen van window.close() in de popup zelf of door het drukken op de escape-toets. Interessant is dat klikken buiten het browservenster de popup niet sluit, wat betekent dat gebruikers meerdere popups tegelijk kunnen openen in verschillende vensters.

Naast deze praktische details is het cruciaal om te begrijpen dat extensies met hun UIs een balans moeten vinden tussen functionaliteit en gebruikerservaring. De restricties van browsers op navigatie en toegang zijn ontworpen om de veiligheid en het gebruiksgemak te waarborgen. Ontwikkelaars moeten daarom zorgvuldig omgaan met permissies en interacties om te voorkomen dat extensies als storend of onveilig worden ervaren. Dit betekent ook dat het ontwerpen van extensie UIs niet alleen gaat over het technisch implementeren van functies, maar ook over het anticiperen op het gedrag van gebruikers en het respecteren van hun controle over de browseromgeving.

Het is daarnaast belangrijk om te beseffen dat de verschillende typen UIs elk hun eigen toepassingsscenario’s hebben. Zo is de popup UI ideaal voor snelle, tijdelijke interacties, terwijl de side panel UI beter geschikt is voor langdurige monitoring of ondersteuning naast het hoofdvenster. De options UI biedt een meer uitgebreide interface voor configuratie, en de devtools pagina’s zijn essentieel voor diepgaande debugging en analyse. Door deze onderscheidingen goed te benutten, kunnen extensies hun functionaliteit optimaliseren zonder het gebruikersgemak aan te tasten.

Hoe kan de chrome.scripting API dynamische injectie van content scripts verbeteren?

Met de introductie van de chrome.scripting API kunnen ontwikkelaars nu op flexibele wijze content scripts injecteren in webpagina's via een programmaatje. Dit biedt aanzienlijke voordelen ten opzichte van traditionele methoden die afhankelijk zijn van de manifestbestanden, wat vaak minder dynamisch is. In deze context biedt de chrome.scripting API een rijke set aan mogelijkheden, die zowel de injectie van JavaScript als CSS omvat. Deze technologie opent de deur voor geavanceerdere browserextensies die op maat gemaakte interacties met webpagina’s kunnen realiseren.

Bij het gebruik van de chrome.scripting.executeScript methode kunnen ontwikkelaars JavaScript direct injecteren in de webpagina. Dit gebeurt door een functie te definiëren en deze uit te voeren in de context van de geladen pagina. Het injecteren van inline functies kan echter niet zonder enige voorzichtigheid. Het belangrijkste om te begrijpen is dat de ingevoegde functie onmiddellijk wordt uitgevoerd en daarna verdwijnt. Dit betekent dat de functies niet persistent zijn, en event listeners die tijdens de injectie zijn ingesteld, bijvoorbeeld chrome.runtime.onMessage, zullen verdwijnen zodra de functie haar taak heeft voltooid. De injectie van inline stijlen via chrome.scripting.insertCSS biedt een vergelijkbare benadering door een stijlregel als een string door te geven, die vervolgens direct wordt toegepast op de webpagina.

Het gebruik van dynamische script tags, die op zichzelf een veelbelovende oplossing lijken, heeft echter beperkingen. Een dynamisch aangemaakte script tag heeft bijvoorbeeld geen toegang tot de WebExtensions API. Dit kan beperkend zijn wanneer specifieke functionaliteit vereist is die alleen via de API kan worden bereikt. Het ontbreken van het import-commando maakt het onmogelijk om specifieke exports uit een module te gebruiken, wat de veelzijdigheid van de dynamische injectie verder reduceert. Hoewel er situaties kunnen zijn waarin het nuttig is om een dynamische script tag te gebruiken, blijft de voorkeur in de meeste gevallen liggen bij dynamische imports. Dit biedt een robuustere en meer controleerbare manier van werken.

Een ander belangrijk aspect is de mogelijkheid om content scripts in te voegen door middel van bestanden. In plaats van inline functies of stijlen, kan de ontwikkelaar externe JavaScript- en CSS-bestanden injecteren. Dit biedt meer structuur en herbruikbaarheid van de code, waardoor het beheer van grotere extensies eenvoudiger wordt. Via de chrome.scripting.executeScript-methode kunnen bestanden met specifieke functies en stijlen naar de pagina worden gebracht, wat zorgt voor een effectievere en schaalbare manier van werken met content scripts.

Daarnaast biedt de chrome.scripting API de mogelijkheid om content scripts dynamisch te registreren en af te melden zonder dat de pagina opnieuw hoeft te laden. Dit kan erg handig zijn wanneer je de injectie van scripts wilt schakelen op basis van gebruikersinteracties. De extensie kan, bijvoorbeeld, bij het klikken op een toolbar-pictogram de injectie van een content script in- of uitschakelen. Deze benadering biedt een hoge mate van controle over het injectieproces, maar het vereist zorgvuldige planning van de logica om te voorkomen dat scripts onbedoeld worden uitgevoerd of niet correct worden verwijderd.

De flexibiliteit van deze API stelt ontwikkelaars in staat om geavanceerdere en interactievere gebruikerservaringen te creëren zonder vast te zitten aan de beperkingen van statische content scripts. Door zowel inline als externe scripts in te voegen, biedt het de mogelijkheid om dynamische, op maat gemaakte inhoud te injecteren die nauw samenwerkt met de bestaande webpagina's.

Het is essentieel te begrijpen dat de injectie van content scripts altijd in de context van de geladen pagina plaatsvindt. Dit betekent dat de inhoud van de webpagina op dat moment direct kan worden gemanipuleerd. Echter, het is ook belangrijk te beseffen dat sommige van de veranderingen die door een content script worden aangebracht, mogelijk niet blijvend zijn wanneer de pagina wordt vernieuwd. Dit komt doordat content scripts slechts tijdelijk zijn en hun effecten verdwijnen zodra de pagina opnieuw wordt geladen.

Ten slotte moeten ontwikkelaars rekening houden met de compatibiliteit van hun extensies. De chrome.scripting API heeft sterke ondersteuning in de meeste moderne browsers, maar verschillen in implementatie kunnen nog steeds bestaan. Het is belangrijk om browser-specifieke beperkingen en verschillen te kennen en te zorgen voor de bredere compatibiliteit van de extensie door gebruik te maken van de browser.* namespace, die in toenemende mate wordt geprefereerd voor cross-browser consistentie.

Hoe gebruik je moderne WebExtensions API-methoden correct en veilig in extensieontwikkeling?

Het gebruik van moderne WebExtensions API's vereist een goed begrip van zowel terugroepfuncties (callbacks) als promises, evenals van de contextuele beperkingen en foutafhandeling. Terwijl de traditionele aanpak gebaseerd was op callbacks, verschuift de moderne ontwikkeling richting het gebruik van async/await, dat zorgt voor leesbaardere en onderhoudbaardere code.

Een simpele boodschap versturen en een antwoord ontvangen kan via een callback of via async/await. Met callbacks ziet dat er als volgt uit:

javascript
Copy code
chrome.runtime.sendMessage("msg", (response) => {
  console.log("Received a response!", response);
});

Maar met async/await kan dit veel netter worden herschreven:

javascript
Copy code
const response = await chrome.runtime.sendMessage("msg");
console.log("Received a response!", response);

Belangrijk om te weten is dat niet alle browser-API’s al zijn aangepast om promises te ondersteunen. Documentatie moet altijd worden geraadpleegd; callbacks zullen altijd blijven werken. Gebruik echter nooit zowel een callback als een promise voor dezelfde methode – kies er één. Als alternatief biedt Mozilla de webextension-polyfill aan. Dit pakket zorgt ervoor dat alle API-methodes consistent werken met promises, ongeacht welke browser wordt gebruikt.

Foutafhandeling verschilt ook tussen callbacks en async/await. Bij gebruik van callbacks is chrome.runtime.lastError beschikbaar binnen de callback om fouten op te vangen. Bij promises daarentegen wordt gebruikgemaakt van .catch() of try/catch:

javascript
Copy code
try {
  await chrome.tabs.executeScript(tabId, details);
} catch(e) {
  // Foutafhandeling
}

Een ander belangrijk aspect is de context waarin een extensie-API beschikbaar is. Niet alle API’s zijn bruikbaar in alle scripts of processen. Zo zijn alarms en runtime.onInstalled alleen beschikbaar in service workers. De devtools.*-API’s zijn beperkt tot de DevTools-context en content scripts hebben geen directe toegang tot veel extensie-API’s. In dat geval moeten zij communiceren met de achtergrondscript via berichten.

Berichtenuitwisseling vormt de kern van communicatie binnen een extensie. Een eenmalig bericht wordt verstuurd met chrome.runtime.sendMessage(), terwijl berichten naar een specifiek tabblad worden verstuurd met chrome.tabs.sendMessage(). De ontvangende kant gebruikt chrome.runtime.onMessage.addListener() om het bericht te verwerken en eventueel te antwoorden.

Bij complexere communicatie of bij een hoge frequentie van berichten is het aan te raden om persistente message ports te gebruiken via chrome.runtime.connect(). Deze ports bieden een bidirectioneel communicatiekanaal tussen verschillende onderdelen van de extensie.

Evenementen vormen een ander belangrijk patroon binnen de WebExtensions-architectuur. Vrijwel elke API maakt gebruik van event listeners via .addListener(), .removeListener(), en .hasListener(). Een voorbeeld is de manier waarop wordt geluisterd naar klikken op de extensieknop:

javascript
Copy code
let count = 0;
function handler() {
  if (++count > 4) {
    chrome.action.onClicked.removeListener(handler);
  }
}
chrome.action.onClicked.addListener(handler);

Het is ook mogelijk om declaratief te filteren welke gebeurtenissen een listener mag ontvangen. Met chrome.webNavigation.onCommitted kan bijvoorbeeld worden gefilterd op specifieke domeinen zoals *.wikipedia.org. Dit voorkomt onnodige overhead in de event handlers.

Ten slotte is het essentieel dat ontwikkelaars inzicht hebben in het machtigingensysteem van extensies. Via chrome.permissions kunnen machtigingen dynamisch worden aangevraagd of gecontroleerd. Het aanvragen van een machtiging kan enkel na een gebruikersactie plaatsvinden:

javascript
Copy code
const permissionsGranted = await chrome.permissions.request({
  permissions: ['tabs']
});

Zorg ervoor dat deze logica niet zomaar op willekeurige momenten in de code wordt aangeroepen, maar alleen wanneer dit expliciet door de gebruiker wordt geïnitieerd.

Voor een robuuste extensie is het onmisbaar om correct te werken met events, asynchrone methodes, foutafhandeling, contextuele API-beperkingen en machtigingen. Een nauwkeurige lezing van de officiële documentatie van zowel Chrome als MDN blijft daarbij onmisbaar. Door de combinatie van gestructureerde eventafhandeling, veilige async-programmering en correcte API-context, ontstaat een extensie die zowel betrouwbaar als schaalbaar is.

Wat verder van belang is, is dat bij het overschakelen van callbacks naar async/await niet alleen de syntax verandert, maar ook de manier waarop fouten, volgorde van uitvoering en afbrekingen worden beheerd. Async/await maakt code eenvoudiger leesbaar, maar introduceert impliciete asynchroniciteit, die zorgvuldig moet worden beheerd. Verder moet men bij gebruik van await altijd zorgen dat de omgeving (bijvoorbeeld de service worker) actief blijft zolang de promise loopt, anders kan de uitvoering onverwacht worden onderbroken. Ook moeten ontwikkelaars rekening houden met backward compatibility: oudere versies van Chromium-gebaseerde browsers ondersteunen mogelijk niet alle moderne syntactische constructies of polyfills. En ten slotte: beperk de afhankelijkheid van undocumented features zoals .dispatch(), die kunnen verdwijnen zonder waarschuwing – baseer je uitsluitend op gestandaardiseerde en goed gedocumenteerde interfaces.

Hoe Google OAuth te configureren voor browserextensies en webtoepassingen

Wanneer je een browserextensie of webtoepassing ontwikkelt die gebruikers wil authenticeren via Google, is het noodzakelijk om OAuth te integreren. Dit proces is complex en vereist een zorgvuldige configuratie om ervoor te zorgen dat de juiste autorisaties en gegevens veilig worden gedeeld tussen je extensie en de Google-services. Hieronder wordt uitgelegd hoe je Google OAuth kunt configureren voor browserextensies, inclusief de verschillende opties die beschikbaar zijn, zoals getAuthToken() en launchWebAuthFlow().

In de Google Cloud-console kun je de OAuth-instellingen voor je extensie configureren. De eerste stap is het creëren van een OAuth-client-ID, wat essentieel is om toegang te krijgen tot de Google API's die je extensie nodig heeft. Google biedt twee hoofdmogelijkheden voor het configureren van OAuth voor extensies: de "Chrome-extensie" en de "Webtoepassing". De keuze tussen deze twee opties hangt af van de manier waarop je de OAuth-authenticatie wilt implementeren.

De optie "Chrome-extensie" maakt gebruik van het oauth2-manifestveld en de getAuthToken()-methode. Dit betekent dat de gebruiker wordt geauthenticeerd via het actieve Google Chrome-profiel, wat niet altijd gewenst kan zijn. Aan de andere kant biedt de optie "Webtoepassing" de launchWebAuthFlow()-methode, die de gebruiker kan authenticeren zonder dat deze gekoppeld is aan het actieve Chrome-profiel, wat meer flexibiliteit biedt voor bepaalde toepassingen.

Zodra je je OAuth-client hebt geconfigureerd in de Google Cloud-console, ontvang je een JSON-bestand met de clientgegevens. Dit bestand bevat essentiële informatie zoals de client_id, project_id, en de URL's voor autorisatie en tokenuitwisseling. Dit bestand moet worden opgenomen in je extensie om OAuth-authenticatie mogelijk te maken.

Bijvoorbeeld, de clientgegevens kunnen eruitzien als volgt:

json
Copy code
{
  "installed": {
    "client_id": "your-client-id.apps.googleusercontent.com",
    "project_id": "your-project-id",
    "auth_uri": "https://accounts.google.com/o/oauth2/auth",
    "token_uri": "https://oauth2.googleapis.com/token",
    "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs"
  }
}

Na de configuratie van de client-ID is het tijd om de authenticatiestroom in je extensie te implementeren. Voor extensies die gebruik maken van de getAuthToken()-methode, wordt de OAuth-token na succesvolle authenticatie automatisch opgeslagen in de cache. De volgende keer dat de extensie de getAuthToken()-methode aanroept, wordt de token uit de cache gehaald zonder dat de gebruiker opnieuw hoeft in te loggen, tenzij dit noodzakelijk is.

json
Copy code
{
  "name": "Google OAuth Example",
  "version": "0.0.1",
  "manifest_version": 3,
  "action": {},
  "background": {
    "service_worker": "background.js",
    "type": "module"
  },
  "permissions": ["identity", "identity.email"],
  "oauth2": {
    "client_id": "your-client-id.apps.googleusercontent.com",
    "scopes": [
      "https://www.googleapis.com/auth/userinfo.email",
      "https://www.googleapis.com/auth/userinfo.profile"
    ]
  }
}

In het bijbehorende JavaScript-bestand kun je de OAuth-stroom initiëren door te luisteren naar een klikgebeurtenis op het extensiepictogram. Zodra de gebruiker zich heeft geauthenticeerd, kun je gebruikersinformatie ophalen via de chrome.identity.getProfileUserInfo()-methode.

javascript
Copy code
chrome.action.onClicked.addListener(() => {
  chrome.identity.getAuthToken({ interactive: true }, (token) => {
    if (token) {
      chrome.identity.getProfileUserInfo({ accountStatus: "ANY" }, (info) => {
        console.log(info);
      });
    }
  });
});

Voor een extensie die OpenID Connect gebruikt, kun je de launchWebAuthFlow()-methode gebruiken. Deze methode vereist dat je handmatig de redirect-URL opgeeft en zorgt voor een flexibele manier om gebruikers te authenticeren zonder het gebruik van het getProfileUserInfo()-methode. De authenticatie wordt geregeld door een JSON Web Token (JWT), dat je kunt analyseren om de gebruiker te identificeren.

json
Copy code
{
  "name": "OpenID Example",
  "version": "0.0.1",
  "manifest_version": 3,
  "action": {},
  "background": {
    "service_worker": "background.js",
    "type": "module"
  },
  "permissions": ["identity"]
}

In de code voor deze benadering wordt de authenticatiestroom als volgt geïnitieerd:

javascript
Copy code
chrome.action.onClicked.addListener(() => {
  const clientId = "your-client-id";
  const redirectUri = chrome.identity.getRedirectURL();
  const nonce = generateNonce();
  const authUrl = buildAuthUrl(clientId, redirectUri, nonce);
  launchAuthFlow(authUrl, (redirectUrl) => {
    if (redirectUrl) {
      const jwt = extractIdToken(redirectUrl);
      if (jwt) {
        const token = parseJwt(jwt);
        console.log(token);
      }
    }
  });
});
function generateNonce() {
  return Math.random().toString(36).substring(2, 15);
}
function buildAuthUrl(clientId, redirectUri, nonce) {
  const authUrl = new URL("https://accounts.google.com/o/oauth2/v2/auth");
  authUrl.searchParams.set("client_id", clientId);
  authUrl.searchParams.set("response_type", "id_token");
  authUrl.searchParams.set("redirect_uri", redirectUri);
  authUrl.searchParams.set("scope", "openid profile email");
  authUrl.searchParams.set("nonce", nonce);
  authUrl.searchParams.set("prompt", "consent");
  return authUrl.href;
}
function launchAuthFlow(authUrl, callback) {
  // Launch OAuth flow and handle response
}

Het is belangrijk om te begrijpen dat het opzetten van OAuth vaak verwarrend kan zijn en dat gedetailleerde configuratie vereist is. De documentatie van de ontwikkelaar kan nuttig zijn, maar het is cruciaal dat je werkt met de juiste client-ID’s, redirect-URLs en scopes om de gebruikersgegevens veilig te verkrijgen. De configuratie verschilt per platform, maar de essentie blijft hetzelfde: je moet de juiste autorisaties verkrijgen en de gebruiker toestemming vragen om toegang te krijgen tot de gegevens die je nodig hebt.