Wat is OAuth en waarom moet je een koppeling af en toe opnieuw 'inloggen'?

Door Clen Mourik

Je koppeling werkt weken perfect, en dan opeens: een foutmelding. Je moet 'opnieuw verbinden'. Waarom? Het antwoord zit in OAuth-tokens — en als je snapt hoe die werken, bespaar je jezelf veel frustratie.

Je systemen praten eindelijk met elkaar. Orders uit je webshop landen automatisch in je boekhouding. Werkbonnen van je installateurs verschijnen direct in AFAS. Geen handmatig overtypen meer. Rust.

Tot die ene maandagochtend. Je opent je laptop en ziet een foutmelding: "401 Unauthorized". De koppeling is gestopt. Facturen komen niet meer binnen. Je moet "opnieuw verbinden". Weer inloggen. Toestemming geven.

Herkenbaar? Dat gevoel van: waarom werkte dit vorige week nog perfect?

Het antwoord zit in OAuth — de beveiligingsstandaard die de meeste moderne softwarekoppelingen draaiende houdt. En hoewel die standaard je bedrijfsgegevens veiliger maakt, zorgt hij ook voor die vervelende herautorisaties. In dit artikel leg ik uit wat OAuth is, waarom tokens verlopen, en — belangrijker — wat je kunt doen om minder vaak opnieuw te hoeven inloggen.

Inhoudsopgave

Belangrijkste punten

Punt Details
OAuth is een beveiligingsstandaard Het is geen login-systeem maar een manier om applicaties tijdelijke, beperkte toegang te geven zonder je wachtwoord te delen
Tokens verlopen om veiligheidsredenen Access tokens zijn vaak maar 1 uur geldig; refresh tokens kunnen maanden meegaan, maar vervallen bij inactiviteit (meestal 30 dagen)
Herlogin is meestal te voorkomen Een goed gebouwde koppeling vernieuwt tokens automatisch op de achtergrond — je merkt er niks van
Grote systemen schakelen over op OAuth AFAS schakelt 'Classic Tokens' uit per 2027; Exact Online hanteert al jaren strenge OAuth-regels
Monitoring voorkomt verrassingen Koppelingen zonder monitoring lopen weken stuk zonder dat je het doorhebt — tot je facturen mist in je boekhouding
OAuth beveiligingsscherm op laptop met autorisatie tokens en inlog interface

Wat is OAuth eigenlijk?

OAuth 2.0 is een autorisatiestandaard vastgelegd in RFC 6749. Dat klinkt technisch, maar het idee erachter is simpel: een applicatie vraagt toestemming om namens jou bepaalde dingen te doen, zonder dat je je wachtwoord hoeft te delen.

Een voorbeeld: je webshop wil orders doorsturen naar Exact Online. Zonder OAuth zou de webshop je Exact-wachtwoord nodig hebben. Gevaarlijk. Met OAuth log je éénmalig in bij Exact, geeft toestemming ("deze webshop mag mijn facturen aanmaken"), en krijgt de webshop een tijdelijk toegangsbewijs — een token.

Dat token is als een pasje voor een specifieke ruimte. Niet je huissleutel (wachtwoord), maar een toegangspas die:

Hoe werkt het technisch?

Kort door de bocht: je klikt op "Verbind met AFAS" in je planningssysteem. Je wordt doorgestuurd naar de AFAS-inlogpagina. Je logt in en geeft toestemming. AFAS stuurt een code terug naar je planningssysteem. Dat systeem wisselt de code in voor twee tokens: een access token (korte levensduur, vaak 1 uur) en een refresh token (langere levensduur, weken tot maanden).

Het access token gebruikt de koppeling om API-verzoeken te doen. Als dat token verloopt, vraagt de koppeling automatisch een nieuw aan via het refresh token. Jij merkt daar niks van — zolang alles goed is gebouwd.

Wat ik in de praktijk zie: de meeste problemen ontstaan niet door OAuth zelf, maar door koppelingen die de token-vernieuwing niet goed afhandelen. Dan werkt alles perfect tot het access token verloopt, en dan... stilte.

Waarom verlopen tokens?

Even eerlijk: het voelt onhandig. Je koppeling werkt, waarom moet dat token dan verlopen?

Het antwoord is beveiliging. Een access token is een sleutel tot jouw bedrijfsdata. Als die sleutel gestolen wordt (bijvoorbeeld doordat een hacker toegang krijgt tot de server waar je koppeling draait), wil je niet dat hij maandenlang geldig blijft. Door tokens snel te laten verlopen, beperk je de schade.

Twee soorten tokens, twee levensduren

Token type Levensduur Gebruik
Access token Kort (15 min - 1 uur) Directe toegang tot de API
Refresh token Lang (weken - maanden) Nieuwe access tokens opvragen
Verloopt bij inactiviteit Meestal na 30 dagen Als de koppeling niet draait

Bij AFAS is een access token bijvoorbeeld precies 1 uur geldig. Daarna moet de koppeling een nieuw token opvragen met de refresh token. AFAS gebruikt roterende refresh tokens: elke keer dat je een nieuw access token opvraagt, krijg je ook een nieuwe refresh token en vervalt de oude.

Exact Online doet iets vergelijkbaars. Bij elke token-refresh wordt de vorige refresh token ongeldig. Dit voorkomt dat oude tokens misbruikt kunnen worden.

De crux: als je koppeling 30+ dagen niet actief is (bijvoorbeeld omdat je even gestopt bent met verkopen, of de koppeling per ongeluk uitgeschakeld was), dan verloopt ook je refresh token. Dan moet je opnieuw inloggen.

Handen bij laptop met OAuth token refresh melding en beveiligingsnotificatie

Praktijkvoorbeelden uit verschillende sectoren

Voorbeeld 1: Webshop met Exact Online koppeling

Een webshop met 200 orders per dag koppelt Shopify aan Exact Online. Elke order wordt automatisch een factuur. Werkt perfect. Tot de eigenaar vier weken op vakantie gaat en de webshop tijdelijk sluit. Bij terugkomst: foutmelding. De refresh token is verlopen door inactiviteit.

Oplossing: opnieuw autoriseren via de OAuth-wizard. Duurt 2 minuten. Daarna draait alles weer. Maar die vier weken gemiste sync? Die moeten handmatig verwerkt worden.

Voorbeeld 2: Zorginstelling met AFAS HR-koppeling

Een zorgorganisatie met 80 medewerkers gebruikt AFAS Profit voor salarisverwerking, gekoppeld aan een extern roosterplanning-systeem. Na een grote update van de planningssoftware verandert de leverancier de redirect URI — het webadres waar AFAS de gebruiker naartoe stuurt na inloggen.

Gevolg: de OAuth-autorisatie werkt niet meer. De koppeling moet opnieuw geconfigureerd worden in het AFAS-portaal. Omdat AFAS roterende refresh tokens gebruikt, en de koppeling door de update tijdelijk niet draaide, is ook de refresh token vervallen.

Lessen: bij grote softwarewijzigingen altijd de OAuth-configuratie checken. En monitoring instellen, zodat je direct een melding krijgt als de koppeling stopt.

Voorbeeld 3: Groothandel met Make-automatisering

Een groothandel gebruikt Make (voorheen Integromat) om orders vanuit een portal door te sturen naar hun CRM. Eenvoudig scenario, werkt maanden goed. Dan wordt het scenario per ongeluk uitgeschakeld (iemand drukte op de verkeerde knop). Drie maanden later willen ze het weer aanzetten: foutmelding. De OAuth-verbinding in Make is verlopen.

No-code platformen beheren token-vernieuwing meestal automatisch, maar als een scenario té lang inactief is, vervalt ook daar de refresh token. Oplossing: in Make de verbinding "herverbinden" via de ingebouwde OAuth-wizard. Duurt 30 seconden.

Bij een klant van ons in de groothandel zagen we dat handmatig orders invoeren hen 15 uur per week kostte. De koppeling werkte perfect, tot een vakantieperiode. Toen die herlogin nodig was, duurde het twee weken voor iemand doorhad dat de automatisering stil lag. Koste hen 30 uur handmatig werk.

5 veelgemaakte fouten die leiden tot herlogin

Fout 1: Koppeling 30+ dagen niet gebruiken

De meest voorkomende reden. Refresh tokens bij AFAS, Exact en de meeste systemen vervallen als ze 30 dagen niet gebruikt worden. Dus: vakantieperiodes, projecten die tijdelijk on hold staan, testsystemen die vergeten worden — allemaal risico's.

Wat werkt: een simpele "heartbeat" inbouwen. Bijvoorbeeld een script dat elke week een lightweight API-call doet, gewoon om de token actief te houden.

Fout 2: Oude refresh token opnieuw gebruiken na rotatie

AFAS en Exact gebruiken roterende refresh tokens. Bij elke vernieuwing krijg je een nieuwe refresh token en vervalt de oude. Veel zelfgebouwde koppelingen slaan die nieuwe token niet goed op. Gevolg: de volgende poging mislukt, en dan moet je handmatig opnieuw autoriseren.

Wat werkt: na elke token-refresh de nieuwe refresh token overschrijven in je database of configuratie. Klinkt logisch, maar in de praktijk gaat dit vaak mis.

Fout 3: Te brede rechten verlenen

Dit leidt niet direct tot herlogin, maar vergroot het risico. Als je bij het autoriseren "alle rechten" aanvinkt (Ctrl+A), geef je de koppeling toegang tot alles. Bij AFAS betekent dit letterlijk toegang tot salarisgegevens, contracten, personeelsdossiers — zelfs als de koppeling alleen facturen hoeft aan te maken.

Wat werkt: geef alleen de rechten die echt nodig zijn. Voor een webshop-koppeling: alleen facturen en relaties. Niet: personeelszaken.

Fout 4: Geen monitoring op tokenfouten

Een koppeling die stilvalt zonder melding is een stille killer. Orders lopen binnen, maar komen niet in je boekhouding. Je merkt het pas weken later, bij de maandafsluiting.

Wat werkt: logging en monitoring. Een goede koppeling stuurt een melding als er drie keer achter elkaar een 401-fout optreedt. Dan weet je meteen dat er iets mis is met de tokens, en kun je ingrijpen voordat er schade ontstaat.

Fout 5: Implicit Grant Flow gebruiken

Dit is een technische, maar cruciale fout. Er zijn verschillende OAuth "flows" — manieren waarop tokens worden uitgegeven. Alleen de Authorization Code Flow ondersteunt refresh tokens. De Implicit Grant Flow doet dat niet. Wie die gebruikt, moet dus regelmatig opnieuw inloggen.

Wat werkt: zorg dat je koppeling de Authorization Code Flow gebruikt. Professionele integratieplatforms zoals SyncIT doen dit standaard goed.

Team analyseert API koppeling dashboard met OAuth status en token monitoring

OAuth vs API keys: wat is het verschil?

Veel MKB-bedrijven werken met API keys. Dat is een vaste sleutel — een lange, cryptische tekenreeks — die je in je software zet. Die sleutel geeft toegang tot de API, vaak zonder vervaldatum.

Voordeel: eenvoudig. Je hoeft nooit opnieuw in te loggen. Nadeel: minder veilig. Als die sleutel lekt, heeft iemand volledige toegang tot je systeem. En je kunt niet beperken wat die sleutel mag — vaak is het alles of niets.

OAuth is verfijnder. Je geeft tijdelijke, beperkte toegang. Je kunt rechten intrekken. Je kunt precies instellen wat een koppeling wel en niet mag. En als een token lekt, is de schade beperkt omdat hij na een uur al verloopt.

Voor interne automatiseringen (bijvoorbeeld een script dat elke nacht data ophaalt) zijn API keys vaak prima. Voor externe apps die klanten zelf autoriseren (bijvoorbeeld een Shopify-app die toegang vraagt tot je webshop) is OAuth de standaard.

Hoe voorkom je handmatige herlogins?

De beste manier om handmatige herlogins te voorkomen is simpel: zorg dat je koppeling actief blijft. Concreet:

Bij SyncIT bouwen we standaard proactieve monitoring in elke koppeling. Als een token dreigt te verlopen, krijg je een melding. Als een API-call faalt, loggen we dat en krijg je een waarschuwing. Zo voorkom je verrassingen.

Kosten en alternatieven

Wat kost het om een OAuth-koppeling te laten bouwen? Voor maatwerk integraties rekent het MKB doorgaans tussen de €3.000 en €15.000, afhankelijk van complexiteit, het aantal systemen en de gewenste foutafhandeling.

Alternatieven:

No-code platformen (Zapier, Make)

Voordeel: snel, geen technische kennis nodig, OAuth-afhandeling ingebouwd. Nadeel: minder controle, beperkte logica, vendor lock-in. Prima voor eenvoudige flows ("nieuwe Typeform-inzending → maak Trello-kaart"). Te beperkt voor complexe bedrijfslogica of maatwerksystemen.

API keys in plaats van OAuth

Voordeel: geen herlogins, eenvoudig. Nadeel: minder veilig, geen fijnmazige rechten. Geschikt voor interne scripts, minder voor klant-geautoriseerde koppelingen.

iPaaS-platformen (Apideck, Workato)

Het midden tussen no-code en maatwerk. Deze platforms beheren OAuth, token-refresh en credential storage. Je bouwt sneller dan volledig maatwerk, maar behoudt meer controle dan bij Zapier. Kosten: variabel, vaak per connector of aantal transacties.

Maatwerk integratie

Volledige controle. De koppeling doet precies wat jij wilt, met robuuste foutafhandeling, logging en monitoring. Hogere initiële investering, maar schaalbaar en toekomstbestendig. Voor bedrijfskritische processen (facturatie, voorraad, salarisverwerking) vaak de beste keuze.

Wil je weten welke aanpak bij jouw situatie past? Plan een vrijblijvend adviesgesprek — we denken graag met je mee.

Veelgestelde vragen

Hoe vaak moet ik opnieuw inloggen bij een OAuth-koppeling?

Bij een goed gebouwde koppeling: nooit. De koppeling vernieuwt tokens automatisch op de achtergrond. Alleen als de refresh token verloopt (meestal na 30 dagen inactiviteit) of als er een configuratiefout is, moet je handmatig opnieuw autoriseren.

Waarom werkte mijn koppeling vorige maand nog wel?

Meestal door een verlopen refresh token. Als je koppeling een maand stil heeft gelegen (bijvoorbeeld tijdens vakantie of door een fout), vervalt de refresh token. Dan moet je opnieuw toestemming geven. Een actieve koppeling heeft dit probleem niet.

Is OAuth veiliger dan een wachtwoord delen?

Absoluut. Met OAuth deel je nooit je wachtwoord. Je geeft tijdelijke, beperkte toegang die je op elk moment kunt intrekken. Als een token lekt, is de schade beperkt — hij verloopt vanzelf. Een gelekt wachtwoord geeft volledige, permanente toegang.

Kan ik OAuth-tokens oneindig lang geldig maken?

Nee, en dat wil je ook niet. Korte levensduur is juist de kracht van OAuth: het beperkt de schade bij een hack. Refresh tokens kunnen lang meegaan (maanden), maar access tokens blijven bewust kort geldig (minuten tot uren).

Wat gebeurt er als AFAS Classic Tokens uitschakelt in 2027?

AFAS schakelt alle Classic Tokens uit uiterlijk 31 augustus 2027. Alle koppelingen moeten dan op OAuth draaien. Heb je nu nog Classic Tokens? Plan dan migratie naar OAuth, bij voorkeur ruim voor de deadline. Wij helpen je graag met de overstap — neem contact op.

Hoe weet ik of mijn koppeling goed met tokens omgaat?

Test het: laat de koppeling een maand draaien zonder handmatige ingrepen. Blijft alles werken? Dan is de token-refresh goed gebouwd. Krijg je foutmeldingen of moet je opnieuw inloggen? Dan is er iets mis met de implementatie. Monitoring helpt: een goede koppeling logt elke token-refresh en stuurt een melding bij fouten.

Tijd om grip te krijgen op je koppelingen

OAuth-tokens voelen soms als een extra complicatie. Waarom kan het niet gewoon altijd werken? Maar die complicatie is precies wat je bedrijfsdata veiliger maakt. Tijdelijke tokens, beperkte rechten, automatische vernieuwing — het zijn lagen van beveiliging die voorkomen dat een hack direct je hele administratie opengooit.

De frustratie zit hem niet in OAuth zelf, maar in koppelingen die het niet goed afhandelen. Een koppeling die tokens niet automatisch vernieuwt. Die geen melding stuurt als er iets misgaat. Die stil stopt met werken en je pas weken later in de problemen brengt.

Dat hoeft niet. Met de juiste opzet draait een OAuth-koppeling jarenlang zonder handmatige ingrepen. Je merkt er niks van — behalve dat je geen orders meer hoeft over te typen, geen dubbele facturen meer ziet, en weer grip hebt op je processen.

Worstel je met koppelingen die regelmatig opnieuw autorisatie vragen? Of wil je een nieuwe integratie bouwen die wel robuust is? Bij SyncIT bouwen we koppelingen zoals ze horen: met proactieve monitoring, correcte token-afhandeling en foutlogs die je daadwerkelijk helpen. Plan een adviesgesprek — we kijken samen naar jouw situatie en denken mee over de beste aanpak.

Over de auteur

Clen Mourik is mede-eigenaar en de technische specialist binnen SyncIT, een Business IT Agency voor het MKB. Vanuit de driehoek van ondernemer, productowner en developer helpt hij bedrijven hun software en processen slimmer te laten samenwerken, zodat er weer rust, grip en ritme ontstaat. Clen schrijft vanuit de dagelijkse praktijk over de knelpunten en kansen van procesautomatisering.