Talrijke API-drivers maken gebruik van OAuth voor de authenticatie. De zogenaamde “Implicit Grant Flow” en de “Code Grant Flow” gebruiken hierbij een tijdelijk wachtwoord genaamd “access token”. De Invantive drivers verzorgen automatisch het telkens opnieuw verkrijgen en gebruik hiervan.
De Code Grant Flow is het grote broertje van de Implicit Grant Flow: naast een zogenaamde “redirect URI” wordt ook een zogenaamde “client secret” gebruikt als app-specifiek wachtwoord om een langduriger geldig wachtwoord te verzinnen. Dit langdurig geldig wachtwoord heet het “refresh token”.
Veel platformen gebruiken OAuth in combinatie met REST of OData zoals: Visma.net, JIRA, Salesforce, Exact Online en Teamleader. Maar OAuth wordt (soms) ook gebruikt met SOAP of XML API’s zoals Twinfield en delen van Exact Online.
Sommige platformen verwachten ook een lijst van scopes om de aanvraag te beperken tot bepaalde onderdelen van de data. Sommige platformen en client applicaties (meestal “app” genaamd) zullen ook eerst om toestemming vragen en diepergaande autorisatie met een TOTP-code (meestal een code bestaande uit een viertal, zestal of achttal cijfers).
Het verversen van de OAuth access tokens gebeurde altijd met een “lazy refresh”; pas zodra het API-platform aangeeft dat het access token niet meer geldig is werd een nieuwe authenticatieslag gemaakt. Dit gaat gepaard met één HTTP 401 melding per 10 minuten op de Exact Online API.
Exact Online gaat naar verluidt een limiet stellen aan het aantal HTTP 4xx meldingen per uur, namelijk 10. Een eerdere studie van 9 juli op de Nederlandse omgeving van Exact Online liet zien dat deze limieten nog niet doorgevoerd zijn. Het is onbekend of en wanneer men deze daadwerkelijk gaat doorvoeren.
Vooruitlopend daarop is toch voor o.a. de Exact Online driver het standaardgedrag aangepast zodat ook in enterprise-omgevingen de kans op onnodige storingen door de lazy refresh van het access token zo klein mogelijk is.
Voortaan wordt standaard bij gebruik van beide flows een API-verzoek 30 seconden voor het einde van de geldigheid van het access token een nieuw access token uitonderhandeld.
Normaliter zal deze termijn van 30 seconden nooit aangepast hoeven te worden. De duur van 30 seconden is instelbaar via de attribuut api-pre-expiry-refresh-sec binnen de limieten van 5 en 3600 seconden. Door een waarde in te stellen hoger dan de normale levensduur van een access token zal bij elk API-request een nieuw access token uitonderhandeld worden.
Als test-case kan het volgende SQL-script gebruikt worden. Het select-statement forceert voor elk Exact Online API-request voor de dagboeken een herauthenticatie leidend tot een nieuw access token:
set use-http-disk-cache false
set use-http-memory-cache false
set api-pre-expiry-refresh-sec 3600
use all
select *
from exactonlinerest..journals
Door dit script met bewust fout gedrag 11x te draaien zou de verwachte nieuwe Exact limiet bereikt moeten worden. Op het moment van schrijven (21 juli 2021) is dit nog niet het geval; er kan onbeperkt een nieuwe access token aangevraagd worden bij de Exact Online API. Dit zal mogelijkerwijs in de toekomst veranderen. Informatie hierover zal gepubliceerd worden op Impact Exact Online API aanpassingen 1 juli 2021.