.svg?width=174&auto=compress,webp&upscale=true "aca-group")
.svg?width=139&auto=compress,webp&upscale=true "aca-group")
6 MEI 2025
Leestijd 5 min
Kamen Zhekov
6 mei 2025
Leestijd 9 min
In deze blogpost wil ik je een overzicht geven van de OAuth 2 specificatie. Toen ik me hierin begon te verdiepen, verdwaalde ik al snel in alle verschillende aspecten. Om ervoor te zorgen dat jij niet hetzelfde hoeft te doen, zal ik OAuth 2 uitleggen alsof je niet eens een technische achtergrond hebt. Omdat er veel te behandelen valt, laten we er meteen in springen!
De kernconcepten van beveiliging
Als het gaat om het beveiligen van een applicatie, zijn er 2 kernconcepten die je in gedachten moet houden:authenticatie en autorisatie.
Authenticatie
Met authenticatie probeer je de vraag "Wie is iemand?" of "Wie is deze gebruiker?" te beantwoorden. Je moet het bekijken vanuit het perspectief van je applicatie of je server. Ze hebben in principe vreemdelingengevaar. Ze weten niet wie je bent en er is geen manier voor hen om dat te weten tenzij je je identiteit aan hen bewijst.Authenticatie is dushet proces om aan de applicatie te bewijzen dat je bent wie je beweert te zijn.
In een voorbeeld uit de echte wereld is dit het verstrekken van je ID of paspoort aan de politie wanneer ze je aan de kant zetten om jezelf te identificeren. Authenticatie is geen onderdeel van de standaard OAuth 2 specificatie. Er is echter een uitbreiding op de specificatie genaamdOpen ID Connect die dit onderwerp behandelt.
Autorisatie
Autorisatie is de keerzijde van authenticatie. Zodra een gebruiker heeft bewezen wie hij is,moet de applicatie uitzoeken wat een gebruiker mag doen. Dat is in wezen wat het autorisatieproces doet.
Een eenvoudige manier om hierover na te denken is het volgende voorbeeld. Als je een leraar bent op een school, heb je toegang tot informatie over de leerlingen in je klas. Als je echter de directeur van de school bent, heb je waarschijnlijk toegang tot de gegevens vanalle leerlingen van de school. Je hebt een grotere toegang vanwege je functie.
OAuth 2 Rollen
Om OAuth 2 volledig te begrijpen, moet je je bewust zijn van de volgende 4 actoren die de specificatie vormen:
- Eigenaar van de bron
- Bronnen server
- Machtigingsserver
- Client / Toepassing
Zoals eerder leggen we het uit met een heel eenvoudig voorbeeld om te zien hoe het echt werkt.
Laten we zeggen dat je een jas hebt. Omdat je de eigenaar bent van die jas, ben je deeigenaar van de bron en de jas is debron die je wilt beschermen. Je wilt het jasje opbergen in een kluisje om het veilig te bewaren. Het kastje zal fungeren als deResource Server. Je bent geen eigenaar van de Resource Server, maar hij bewaart je spullen voor je. Omdat je wilt voorkomen dat het jasje door iemand anders wordt gestolen, moet je een slot op het kastje zetten. Dat slot is deautorisatieserver. Deze regelt de beveiligingsaspecten en zorgt ervoor dat alleen jij toegang hebt tot de jas of mogelijk iemand anders die jij toestemming geeft. Als je wilt dat je vriend je jasje uit het kastje haalt, dan kan die vriend gezien worden als deClient of Applicatie actor in de OAuth flow. DeClient handelt altijd namens de gebruiker.
Tokens
Het volgende concept waar je veel over zult horen is tokens. Er zijn verschillende soorten tokens, maar ze zijn allemaal heel eenvoudig te begrijpen. De 2 soorten tokens die je het meest tegenkomt zijnaccess tokens en refresh tokens.
Als het gaat om toegangsmunten, heb je misschien wel eens gehoord van JWT-tokens, tokens aan toonder of opake tokens. Dat zijn eigenlijk alleen maar implementatiedetails die ik in dit artikel niet ga behandelen.
In essentie is een toegangstoken iets dat je aan de resource server geeft om toegang te krijgen tot de items die hij voor je bewaart. Je kunt toegangsmunten bijvoorbeeld zien als papieren kaartjes die je op de kermis koopt. Als je in een attractie wilt stappen, laat je je ticket zien aan de persoon in het hokje en die laat je instappen. Je maakt een ritje en na afloop verloopt je ticket. Belangrijk om te weten is datwie het token heeft, eigenaar is van het token. Wees er dus heel voorzichtig mee. Als iemand anders je token in handen krijgt, kan hij of zij namens jou toegang krijgen tot je items!
Refresh tokens lijken erg op access tokens. In wezen gebruik je ze om meer toegangsmunten te krijgen. Toegangsmunten hebben meestal een korte levensduur, maar verversingsmunten hebben vaak een langere vervaldatum. Om terug te komen op ons kermisvoorbeeld, een verversingstoken zou de creditcard van je ouders kunnen zijn die kan worden gebruikt om meer kermiskaartjes te kopen die je kunt uitgeven aan attracties.
Scopes
Het volgende concept dat we behandelen zijn scopes. Een scope is in feite een beschrijving van dingen die een persoon kan doen in een applicatie. Je kunt het zien als een functie in het echte leven (bijvoorbeeld een directeur of leraar op een middelbare school). Bepaalde scopes geven je meer rechten dan andere.
Ik weet dat ik zei dat ik niet in technische details zou treden, maar als je bekend bent met Spring Security, dan kun je scopes vergelijken met wat Spring Security rollen noemt. Een scope komt één op één overeen met het concept van een rol.
De OAuth specificatie specificeert niet hoe een scope eruit moet zien, maar vaak zijn het punt-gescheiden Strings zoalsblog.write. Google daarentegen gebruikt URL's als scope. Als voorbeeld: om alleen-lezen toegang tot iemands agenda toe te staan, geven ze de scopehttps://www.googleapis.com/auth/calendar.readonly.
Toelage types
Types van toekenningen zijn typisch waar dingen verwarrend beginnen te worden voor mensen. Laten we beginnen met het tonen van de meest gebruikte grant types:
- Clientgegevens
- Machtigingscode
- Apparaatcode
- Vernieuwen
- Wachtwoord & impliciet
Client Credentials is een type toekenning dat vaak wordt gebruikt als 2 back-end diensten op een veilige manier met elkaar moeten communiceren.
De volgende is het grant typeAuthorization Code, wat waarschijnlijk het moeilijkste grant type is om volledig te begrijpen. Je gebruikt dit type grant wanneer je gebruikers wilt laten inloggen via een browsergebaseerd aanmeldformulier. Als je ooit de knop 'Log in met Facebook ' of 'Log in met Google' op een website hebt gebruikt, dan heb je zonder het te weten al een autorisatiecodestroom ervaren!
De volgende is het toestemmingscodetype , dat vrij nieuw is in de OAuth 2-scene. Het wordt meestal gebruikt op apparaten met beperkte invoermogelijkheden, zoals een TV. Als je bijvoorbeeld wilt inloggen op Netflix, in plaats van je gebruikersnaam en wachtwoord op te geven, verschijnt er een link met een code die je moet invullen met de mobiele app.
HetRefresh grant type gaat meestal hand in hand met de Authorization Code flow. Omdat toegangstokens een korte levensduur hebben, wil je niet dat je gebruikers telkens moeten inloggen als het toegangstoken verloopt. Dus is er deze refresh flow die refresh tokens gebruikt om nieuwe access tokens te verkrijgen wanneer ze bijna verlopen zijn.
De laatste 2 toekenningsvormen zijnWachtwoord en Impliciet. Deze toekenningsvormen zijn minder veilige opties die niet worden aanbevolen bij het bouwen van nieuwe applicaties. We zullen ze kort behandelen in de volgende sectie, waarin de bovenstaande toekenningsvormen in meer detail worden uitgelegd.
Autorisatie stromen
Een autorisatiestroom bevat een of meer stappen die moeten worden uitgevoerd om een gebruiker te autoriseren door het systeem. Er zijn 4 autorisatiestromen die we zullen bespreken:
- Client Credentials stroom
- Wachtwoord stroom
- Autorisatie Code stroom
- Impliciete stroom
Client Credentials stroom
De Client Credentials stroom is de eenvoudigste stroom om te implementeren. Het werkt ongeveer hetzelfde als hoe een traditionele gebruikersnaam/wachtwoord login werkt.Gebruik deze flow alleen als je de client/applicatie kunt vertrouwen, omdat de client credentials worden opgeslagen binnen de applicatie. Gebruik dit niet voor single page apps (SPA's) of mobiele apps, omdat kwaadwillende gebruikers de app kunnen deconstrueren om de credentials te bemachtigen en deze te gebruiken om toegang te krijgen tot beveiligde bronnen. In de meeste use cases wordt deze flow gebruikt om veilig te communiceren tussen 2 back-end systemen.
Hoe werkt de Client Credentials stroom? Elke applicatie heeft een client ID en secret die geregistreerd zijn op de autorisatieserver. De applicatie presenteert deze aan de autorisatieserver om een toegangstoken te krijgen en gebruikt het om de beveiligde bron van de resource server te krijgen. Als op een bepaald moment het toegangstoken verloopt, herhaalt hetzelfde proces zich om een nieuw token te krijgen.
Wachtwoord stroom
De Password flow lijkt erg op de Client Credentials flow, maar is erg onveilig omdat er een 3e actor bij betrokken is, namelijk een daadwerkelijke eindgebruiker. In plaats van een veilige client die we vertrouwen die een ID en geheim aan de autorisatie provider presenteert, hebben we nu een gebruiker die met een client 'praat'. In een Password flow geeft de gebruiker zijn persoonlijke gegevens aan de client. De client gebruikt deze gegevens om toegangstokens te krijgen van de autorisatieserver. Dit is de reden waarom een Password flow niet veilig is, omdatwe er absoluut zeker van moeten zijn dat we kunnen vertrouwen dat de client de credentials niet misbruikt voor kwaadaardige redenen.
Uitzonderingen waarbij deze flow nog steeds gebruikt zou kunnen worden zijn commandoregelapplicaties of bedrijfswebsites waarbij de eindgebruiker de client-apps moet vertrouwen die hij dagelijks gebruikt. Maar afgezien hiervan wordt het niet aanbevolen om deze flow te implementeren.
Autorisatie Code Stroom
Dit is de stroom die je zeker wilt begrijpen, omdat het de stroom is die het meest wordt gebruikt bij het beveiligen van applicaties met OAuth 2. Deze stroom is iets gecompliceerder dan de eerder besproken stromen. Het is belangrijk om te begrijpen datdeze flow vertrouwelijk, veilig en browsergebaseerd is.
De flow werkt door veel HTTP redirects te maken, daarom is een browser een belangrijke speler in deze flow. Er is ook een back-channel verzoek (zo genoemd omdat de gebruiker niet betrokken is bij dit deel van de stroom) waarbij de client of applicatie rechtstreeks met de autorisatieserver praat. In deze flow moet de gebruiker meestal de scopes of rechten goedkeuren die aan de applicatie worden toegekend. Een voorbeeld hiervan is een applicatie van derden die vraagt of je toegang mag krijgen tot je Facebook-profielfoto nadat je bent ingelogd met de knop 'Aanmelden met Facebook'.
Laten we de Autorisatiecode-flow toepassen op ons voorbeeld 'jas in de kast' om een beter begrip te krijgen.
Onze jas ligt in de kast en we willen hem uitlenen aan een vriend. Onze vriend gaat naar het (hightech) kluisje. Het kastje belt ons, want wij zijn de Resource Owner. Deze oproep is een van die redirects waar we het eerder over hadden. Op dit punt maken we een beveiligde verbinding met het kastje, dat fungeert als een autorisatieserver. We kunnen nu veilig onze referenties geven om toestemming te geven om het slot te ontgrendelen. De autorisatieserver verstrekt vervolgens een tijdelijke code, de OAuth-code, aan onze vriend. De vriend gebruikt vervolgens die OAuth-code om een toegangscode te verkrijgen om het kastje te openen en mijn jas te pakken.
Impliciete stroom
Deimpliciete flow is in principe hetzelfde als de autorisatiecode flow, maar dan zonder de tijdelijke OAuth code. Dus na het inloggen stuurt de autorisatieserver direct een toegangstoken terug zonder dat er een back-channelverzoek nodig is. Dit is minder veilig, omdat het token onderschept kan worden via een man-in-the-middle aanval.
Conclusie
OAuth 2 kan er in eerste instantie ontmoedigend uitzien vanwege alle verschillende actoren die erbij betrokken zijn. Hopelijk begrijp je nu beter hoe ze met elkaar samenwerken. Met deze kennis in je achterhoofd is het veel gemakkelijker om de technische details te begrijpen als je je er eenmaal in begint te verdiepen.
Related articles
What others have also read
Leestijd 8 min
Dorien Jorissen
8 MEI 2025
Bij de ontwikkeling van software kunnen aannames ernstige gevolgen hebben en we moeten altijd op onze hoede zijn. In deze blogpost bespreken we hoe je omgaat met aannames bij het ontwikkelen van software. Stel je voor... je rijdt naar een bepaalde plaats Een plek waar je al 5 jaar lang elke dag naartoe rijdt, dezelfde route neemt, langs dezelfde verlaten straat rijdt, waar je nog nooit een andere auto hebt gezien. Langzamerhand begin je je vertrouwd te voelen met deze route en ga je ervan uit dat je zoals altijd de enige auto op deze weg zult zijn. Maar op een gegeven moment duikt er een auto vlak voor je op... er was al die tijd al een zijstraat, maar je had hem nooit opgemerkt, of misschien was je hem helemaal vergeten. Je trapt op de rem en komt gelukkig net op tijd tot stilstand. Aannames werden je bijna fataal. Gelukkig zijn de veronderstellingen die we in ons werk maken nooit zo gevaarlijk voor ons leven als de veronderstellingen die we in het verkeer maken. Toch kunnen veronderstellingen ernstige gevolgen hebben en moeten we altijd op onze hoede zijn. Stel je voor... je maakt websites Je laatste klant is op zoek naar een nieuwe site voor zijn bejaardentehuis omdat zijn huidige site verouderd en niet zo fancy is. Dus u bouwt een fancy nieuwe website in de veronderstelling dat fancy betekent: modern ontwerp, sociale functies, dynamische inhoud. De site is niet het succes dat hij had verwacht ... vreemd ... je hebt precies gebouwd wat je klant wil. Maar heeft u gebouwd wat de bezoekers van de site willen? De gemiddelde gebruiker is tussen de 50 - 65 jaar oud, op zoek naar een nieuw huis voor hun vader en moeder. Ze zijn geen digital natives en voelen zich misschien niet thuis op een mooie, dynamische website vol twitterfeeds en sociale knoppen. Het enige wat ze willen is een goede indruk krijgen van het bejaardentehuis en gerustgesteld worden over het feit dat er goed voor hun ouders zal worden gezorgd. Hoe meer ervaring je krijgt, hoe harder je moet oppassen geen aannames te doen en dubbel te checken met je klant EN de doelgroep . Een ander bekend gevaar van ervaring is " de vloek van de kennis ". Hoewel het klinkt als de volgende Pirates of the Caribbean sequel, is de vloek van kennis een cognitieve bias die bijna iedereen met expertkennis in een specifieke sector overheerst. Het betekent dat beter geïnformeerde partijen het extreem moeilijk vinden om over problemen na te denken vanuit het perspectief van minder goed geïnformeerde partijen. Je kunt je afvragen waarom economen er niet altijd in slagen om de juiste beursvoorspellingen te doen. Iedereen die wat geld over heeft, kan aandelen kopen. Je hoeft geen expert te zijn of zelfs maar verstand te hebben van economie. En dat is de belangrijkste reden waarom economen er vaak naast zitten. Omdat ze expertkennis hebben, kunnen ze niet voorbij deze expertise kijken en kunnen ze zich moeilijk voorstellen hoe minder geïnformeerde mensen zullen reageren op veranderingen in de markt. Hetzelfde geldt voor IT. Daarom moeten we altijd een oogje in het zeil houden en blijven we in de huid kruipen van onze klanten. Inzicht krijgen in hun ervaring en standpunt is de sleutel tot het creëren van de perfecte oplossing voor de eindgebruiker. Dus hoe pakken we aannames aan ...? Ik zou graag zeggen "Eenvoudig" en je een prachtige oneliner geven ... maar zoals gewoonlijk ... is eenvoudig nooit het juiste antwoord. Om de drang om over te schakelen op de automatische piloot en de vloek van de kennis te laten werken, hebben we een methodologie ontwikkeld op basis van verschillende Agile-principes die ons dwingt om onze eindgebruiker te betrekken bij elke fase van het project, te beginnen wanneer onze klanten nadenken over een project, maar de oplossing nog niet hebben gedefinieerd. En eindigt... nou eigenlijk nooit. De eindgebruiker zal nieuwe inzichten opdoen door met uw oplossing te werken, wat kan leiden tot nieuwe verbeteringen. In de watervalmethode wordt aan het begin van een project een analyse gemaakt door een business analist. Soms wordt de gebruiker betrokken bij deze voorafgaande analyse, maar dit is niet altijd het geval. Dan maakt een conclaaf van ontwikkelaars iets in eenzaamheid en na de witte rook ... begint het gebruikersacceptatietesten (UAT) . Het moet pijnlijk voor ze zijn om zich na deze tests te realiseren dat het product dat ze zorgvuldig hebben gemaakt niet de oplossing is die de gebruikers ervan verwachtten. Het is te laat om ingrijpende veranderingen door te voeren zonder dat daar veel meer tijd en budget voor nodig is. Met een Agile projectmethodologie kom je een heel eind. Door elke 2 tot 3 weken testbare versies uit te brengen, kunnen gebruikers geleidelijk functionaliteit testen en hun feedback geven tijdens de ontwikkeling van het project. Deze aanpak houdt rekening met de inzichten van de gebruiker, die tijdens het project zijn opgedaan, en garandeert een betere match tussen de behoeften van de gebruiker en de oplossing die je voor hun behoeften creëert. Agile beoefenaars zijn voorstander van 'continuous deployment'; een praktijk waarbij nieuw ontwikkelde functies onmiddellijk worden uitgerold naar een productieomgeving in plaats van in batches om de 2 tot 3 weken. Dit stelt ons in staat om het systeem (en in essentie de aannames) in het wild te valideren, waardevolle feedback van echte gebruikers te krijgen en gerichte experimenten uit te voeren om te valideren welke aanpak het beste werkt. Door onze methodologie te combineren met constante betrokkenheid van gebruikers, elimineer je de ergste aanname in IT: we weten hoe de werknemers hun werk doen en wat ze nodig hebben ... het gevaar van ervaring! Elimineren we altijd aannames? Laat me het iets ingewikkelder maken: Nogmaals... stel je voor: je gaat al 10 jaar naar dezelfde supermarkt, het is vrij veilig om aan te nemen dat de cornflakes nog steeds in hetzelfde gangpad liggen, zelfs op hetzelfde schap als gisteren. Als je niet meer zou aannemen waar de cornflakes liggen... dan zou je enorm veel tijd verliezen door de hele winkel door te lopen. Niet één keer, maar steeds opnieuw. Hetzelfde geldt voor ons werk. Als we ons werk zouden doen zonder te vertrouwen op onze ervaring, zouden we geen inschattingen kunnen maken over budget en tijd. Elke schatting is gebaseerd op aannames. Hoe meer ervaring je hebt, hoe nauwkeuriger deze aannames worden. Maar leiden ze ook tot goede en betrouwbare schattingen? Niet noodzakelijk ... Terug naar mijn metafoor ... We nemen elke dag dezelfde weg naar het werk. Op basis van ervaring kan ik inschatten dat ik er 30 minuten over zal doen om naar mijn werk te rijden. Maar wat als ze files aankondigen op de radio en ik de aankondiging niet heb gehoord ... dan is mijn schatting niet juist. Bij ACA Group gebruiken we een aantal belangrijke werkwijzen bij het maken van schattingen. Ten eerste is het een teamsport. We maken nooit schattingen in ons eentje en hoewel schatten een serieuze zaak is, doen we het terwijl we een spelletje spelen: Planningspoker. Laat me je dit uitleggen; planning poker is gebaseerd op het principe dat we beter kunnen inschatten in een groep. Dus we lezen het verhaal (stuk functionaliteit) hardop voor, iedereen pakt een kaart (die een indicatie geeft van de complexiteit) en legt deze open op tafel. Als iedereen een kaart heeft gekozen, worden ze allemaal tegelijk omgedraaid. Als er verschillende getallen worden getoond, ontstaat er een discussie over het waarom en hoe. Veronderstellingen die de basis vormen voor iemands schatting komen naar boven en worden besproken en gevalideerd. Er volgt nog een schattingsronde en het proces gaat door tot er consensus is bereikt. Het eindresultaat: een betere schatting en een grondig begrip van de aannames die aan de schatting ten grondslag liggen. Deze expliciete aannames zijn er om gevalideerd te worden door onze belanghebbenden; een geweldig eerste hulpmiddel om ons begrip van de scope te valideren.Dus elimineren we altijd aannames? Nou, dat zou bijna onmogelijk zijn, maar door aannames expliciet te maken elimineren we een hoop verspilling. Wil je meer weten over deze Agile Estimation? Bekijk dan dit boek van Mike Cohn . Hé, dit is een tegenstrijdigheid... Hoe zit het dan met die aannames? Moeten we ze proberen te vermijden? Of moeten we erop vertrouwen? Als je ervan uitgaat dat je alles weet... zul je nooit meer verbazing ervaren. Zoals Aristoteles al zei: "Het was hun verwondering, verbazing, die de mensen ertoe bracht om te filosoferen". Welnu, een proces dat de gemaakte veronderstellingen valideert door middel van goed uitgevoerde experimenten en snelle feedback heeft bewezen geweldige resultaten op te leveren. Dus in essentie zal het goed beheren van je aannames prachtige dingen opleveren. Wees je er wel van bewust dat de vloek van kennis om de hoek loert, wachtend op een onbewaakt moment om het over te nemen. Geïnteresseerd in deelname aan ons team? Wil je een van onze teamleden ontmoeten? Geïnteresseerd om deel uit te maken van ons team? We zijn altijd op zoek naar nieuwe gemotiveerde professionals om het ACA-team te versterken! {% module_block module "widget_3ad3ade5-e860-4db4-8d00-d7df4f7343a4" %}{% module_attribute "buttons" is_json="true" %}{% raw %}[{"appearance":{"link_color":"light","primary_color":"primary","secondary_color":"primary","tertiary_color":"light","tertiary_icon_accent_color":"dark","tertiary_text_color":"dark","variant":"primary"},"content":{"arrow":"right","icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"tertiary_icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"text":"View career opportunities"},"target":{"link":{"no_follow":false,"open_in_new_tab":false,"rel":"","sponsored":false,"url":{"content_id":229022099665,"href":"https://25145356.hs-sites-eu1.com/en/jobs","href_with_scheme":null,"type":"CONTENT"},"user_generated_content":false}},"type":"normal"}]{% endraw %}{% end_module_attribute %}{% module_attribute "child_css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "definition_id" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "field_types" is_json="true" %}{% raw %}{"buttons":"group","styles":"group"}{% endraw %}{% end_module_attribute %}{% module_attribute "isJsModule" is_json="true" %}{% raw %}true{% endraw %}{% end_module_attribute %}{% module_attribute "label" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "module_id" is_json="true" %}{% raw %}201493994716{% endraw %}{% end_module_attribute %}{% module_attribute "path" is_json="true" %}{% raw %}"@projects/aca-group-project/aca-group-app/components/modules/ButtonGroup"{% endraw %}{% end_module_attribute %}{% module_attribute "schema_version" is_json="true" %}{% raw %}2{% endraw %}{% end_module_attribute %}{% module_attribute "smart_objects" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "smart_type" is_json="true" %}{% raw %}"NOT_SMART"{% endraw %}{% end_module_attribute %}{% module_attribute "tag" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "type" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "wrap_field_tag" is_json="true" %}{% raw %}"div"{% endraw %}{% end_module_attribute %}{% end_module_block %}
Lees verder
Leestijd 4 min
Dorien Jorissen
8 MEI 2025
ACA doet veel projecten. In het laatste kwartaal van 2017 deden we een vrij klein project voor een klant in de financiële sector. De deadline voor het project was eind november en onze klant werd eind september ongerust. We hadden er echter alle vertrouwen in dat we de klus op tijd konden klaren en besloten een experiment uit te proberen. We brachten het team samen in één kamer en begonnen met mob-programmering . Maffia wat? We hadden een artikel gelezen waarin het concept van mob programming werd uitgelegd. In het kort komt mob programming erop neer dat het hele team samen in één ruimte zit en aan één user story tegelijk werkt. Eén persoon is de 'bestuurder' en doet het coderen voor een bepaalde tijd. Als die tijd voorbij is, gaat het toetsenbord over naar een ander teamlid. We probeerden het experiment met de volgende opzet: Ons team was relatief klein en had slechts 4 teamleden. Omdat het project waaraan we werkten relatief klein was, konden we maar 4 mensen aannemen. De user stories die we behandelden waren slechts een deel van het project. Omdat dit een experiment was, wilden we niet dat het project - zo klein als het was - volledig zou worden overspoeld. Daarom kozen we één specifieke epic en implementeerden we die user stories in de mob. We werkten niet op dezelfde computer. We hadden elk een aparte laptop en checkten onze code in op een centraal versiebeheersysteem in plaats van het toetsenbord te verwisselen. Dit was niet echt een keuze die we maakten, gewoon iets dat gebeurde. We wisselden elke 20 minuten. Het artikel waarnaar we verwezen heeft het over 12, maar we vonden dat te kort en besloten om in plaats daarvan 20 minuten te nemen. Klaar, af, af! We brachten meer dan een week door in een vergaderruimte waar we om de beurt onze laptops konden aansluiten op één groot scherm. De eerste dag van het experiment ontwierpen we. Urenlang stonden we achter het whiteboard om te beslissen over de architectuur van de component die we gingen bouwen. Op dezelfde dag begon onze groep met de implementatie van het eerste verhaal. We gingen er echt vandoor! We vlogen door de user story en riepen naar onze klantproxy als sommige vereisten niet duidelijk waren. Tegen het einde van de dag waren we uitgeput. Ons experiment was nog maar net begonnen en het was al zo intens. De volgende dagen gingen we verder met het implementeren van de user stories. In minder dan een week hadden we werkende software die we aan onze klant konden laten zien. Hoewel het nog niet perfect was en niet alle vereisten dekte, was onze software al na 3 dagen in staat om een volledige, gelukkige path flow uit te voeren. Twee dagen later implementeerden we verbeteringen en uitzonderingsgevallen die via andere user stories waren besproken. Er was nog maar een week verstreken sinds onze klant zich zorgen begon te maken en we hadden al zoveel geïmplementeerd dat we hem konden laten zien. De laatste hand leggen Tegen het einde van het project moesten we alleen nog wat technische zaken regelen. Een daarvan was het agnostisch maken van onze nieuw gebouwde softwareomgeving. Als we deze user story hadden afgewerkt met pair programming, zou één paar alle technische details van de software kennen. Met pair programming hoefden we het niet aan de rest van het team te laten zien. Het team wist het al. Omdat we laptops gebruikten in plaats van toetsenborden, had iedereen de setup op zijn eigen machine gedaan. Iedereen kende de commando's en de configuratie. Het was kennis delen op zijn best! Andere technische aspecten waren het correct configureren van onze software. Dit bleek een saaie taak te zijn voor de meeste navigators. Op dit punt besloten we dat het maffia-experiment ver genoeg was gegaan. We hadden het gevoel dat het niet de bedoeling was om dit soort taken met 4 mensen tegelijk te doen. Tenminste, dat is onze mening. Vlak voordat de groep uiteenviel, planden we een evaluatiebijeenkomst. We waren enthousiast en wilden dit opnieuw doen, misschien zelfs op grotere schaal. Onze ervaring met mob-programmering Het resultaat van ons experiment was erg positief. We ervoeren kennisdeling op verschillende niveaus. Alle betrokkenen kenden de volledige functionaliteit van de applicatie en we kenden allemaal de details van de implementatie. We waren in staat om snel een nieuw teamlid te integreren wanneer dat nodig was, terwijl we toch op een constante snelheid bleven werken. We hadden al gezegd dat we erg enthousiast waren voor, tijdens en na het experiment. Dit had een positieve invloed op onze teamgeest. We waren allemaal meer betrokken bij het project. Het nadeel was dat we mob-programmeren als vermoeiender ervoeren. We voelden ons uitgeput na een dag samenzijn, zij het op een goede manier! Volgende stappen Andere collega's zagen ons in onze vergaderruimte programmeren op een groot scherm. Er ontstonden gesprekken over het experiment. Onze opwinding werkte aanstekelijk: mensen waren meteen geïnteresseerd. We begonnen te praten over meer experimenten. Misschien zouden we mob-programmering kunnen doen in verschillende teams op verschillende projecten. En zo begint het... Heb jij ooit al eens mob-programmering geprobeerd? Of sta je te popelen om het te proberen? Laten we tips of trucs uitwisselen! We horen graag van je !
Lees verder
Leestijd 4 min
Gregory Van Dorpe
8 MEI 2025
OutSystems: een katalysator voor bedrijfsinnovatie In het snelle zakelijke landschap van vandaag de dag moeten organisaties innovatieve oplossingen omarmen om voorop te blijven lopen. Er zijn veel strategische technologische trends die cruciale bedrijfsprioriteiten aanpakken, zoals digitale immuniteit, composability, AI, platform engineering, Low-Code en duurzaamheid. OutSystems , het toonaangevende Low-Code ontwikkelplatform , is een game-changer geworden in het ondersteunen van organisaties om deze trends efficiënt en duurzaam te implementeren. OutSystems verbetert cyberbeveiliging Omdat organisaties steeds meer vertrouwen op digitale systemen, vormen cyberbedreigingen een aanzienlijk risico. Daarnaast speelt de digitale interactie met klanten, medewerkers en partners een vitale rol in het welzijn van een bedrijf. De immuniteit en veerkracht van een organisatie is nu net zo sterk en stabiel als de digitale kernsystemen. Elke onbeschikbaarheid kan leiden tot een slechte gebruikerservaring, inkomstenverlies, veiligheidsproblemen en meer. OutSystems biedt een robuust en veilig platform dat helpt bij het opbouwen van digitale immuunsystemen die bescherming bieden tegen evoluerende cyberbeveiligingsuitdagingen. Met geavanceerde detectie van bedreigingen, continue monitoring, veilige codeerpraktijken en AI-code-scanning zorgt OutSystems ervoor dat applicaties veerkrachtig en beschermd zijn. Bovendien dekt het platform de meeste beveiligingsaspecten voor projectteams, zodat zij zich kunnen richten op het leveren van hoge waarde aan eindklanten, terwijl best practices door het platform worden aanbevolen door middel van codeanalyse met behulp van ingebouwde patronen. OutSystems vereenvoudigt het beheer van cloud-native infrastructuur Cloud-native architectuur is een essentieel onderdeel geworden voor moderne applicatieontwikkeling. Het OutSystems Developer Cloud Platform stelt teams in staat om eenvoudig cloud-native applicaties te maken en in te zetten, waarbij gebruik wordt gemaakt van de schaalbaarheid en flexibiliteit van cloud-infrastructuur via Kubernetes . Het stelt bedrijven in staat om: Het gebruik van resources te optimaliseren Applicatieruntimes automatisch schalen Operationele kosten verlagen Duurzame praktijken toe te passen (serverless computing, automatisch schalen, ...) Dit alles zonder de noodzaak om vooraf te investeren in infrastructuur of de diepgaande technische kennis die nodig is om het te bedienen en de typische lasten die daarmee gepaard gaan. OutSystems: toegangspoort tot AI en automatisering AI en hyperautomatisering zijn essentiële zakelijke hulpmiddelen geworden voor hulp bij het maken van content, virtuele assistenten, snellere codering, documentanalyse en nog veel meer. OutSystems stelt professionele ontwikkelaars in staat productiever te zijn door AI in te bouwen in de gehele levenscyclus van applicaties. Ontwikkelaars profiteren van AI-ondersteunde ontwikkeling, query's in natuurlijke taal en zelfs generatieve AI. Als je eenmaal klaar bent met je ontwikkeling, is het transporteren van een app naar de test- of productieomgeving slechts een kwestie van een paar klikken. Het platform automatiseert het proces in hoge mate en voert zelfs alle noodzakelijke validaties en afhankelijkheidscontroles uit om onbreekbare implementaties te garanderen. OutSystems integreert naadloos met AI-mogelijkheden van grote cloudproviders zoals Amazon, Azure (OpenAI) en Google, waardoor projectteams gebruik kunnen maken van generatieve AI, machine learning, natuurlijke taalverwerking en computervisie . Door geavanceerde technologieën toegankelijker te maken, versnelt OutSystems digitale transformatie en creëert het duurzame concurrentievoordelen. OutSystems maakt samengestelde architectuur voor flexibiliteit mogelijk Composable architectuur en business apps, gekenmerkt door modulaire componenten, maken snelle aanpassing aan veranderende bedrijfsbehoeften mogelijk. OutSystems omarmt deze trend door een cloud-native Low-Code platform te bieden dat dit type architectuur gebruikt en ondersteunt. Het stelt teams in staat om eenvoudig samenstelbare technische en zakelijke componenten te bouwen. Met de visuele modelleerbenadering van Low-Code, een uitgebreide bibliotheek van aanpasbare vooraf gebouwde componenten en een microservice-gebaseerd applicatieleveringsmodel, bevordert OutSystems hoge herbruikbaarheid en flexibiliteit. Deze samengestelde aanpak stelt organisaties in staat om: Snel te reageren op veranderende bedrijfsbehoeften Te experimenteren met nieuwe ideeën Duurzame, schaalbare en veerkrachtige oplossingen te creëren OutSystems maakt de creatie van bedrijfsapps mogelijk die eenvoudig kunnen worden geïntegreerd, vervangen of uitgebreid, en ondersteunt bedrijven op hun reis naar combineerbaarheid en flexibiliteit. OutSystems vergemakkelijkt self-service en nauwe samenwerking Platform engineering, dat de nadruk legt op samenwerking tussen ontwikkelings- en operationele teams, zorgt voor efficiëntie en schaalbaarheid. OutSystems biedt een gecentraliseerd Low-Code platform dat dit concept in de kern omarmt door voortdurend te worden uitgebreid met nieuwe functies, tools en versnellers. Bovendien faciliteert het platform de gehele levenscyclus van applicatieontwikkeling tot aan operations . Inclusief functies zoals Versiebeheer Geautomatiseerde implementatie Continue integratie en levering (CI/CD) Registratie Bewaking Organisaties in staat stellen om agile DevOps-praktijken toe te passen. Met OutSystems kunnen cross-functionele teams naadloos samenwerken, waardoor een snellere time-to-market en een betere softwarekwaliteit mogelijk worden. Door platform engineering principes te ondersteunen, helpt OutSystems organisaties om duurzame softwarelevering en operationele uitmuntendheid te bereiken. OutSystems stimuleert duurzaamheid in IT OutSystems leidt de weg in het stimuleren van duurzaamheid in IT door middel van zijn groene IT Low-Code applicatie-ontwikkelplatform en strategische initiatieven. Door energie-efficiënte ontwikkeling mogelijk te maken , het beheer van de levenscyclus van applicaties te stroomlijnen , gebruik te maken van een cloud-native infrastructuur en herbruikbaarheid te bevorderen, stelt OutSystems een voorbeeld voor de branche. Organisaties kunnen papierloze processen ontwikkelen, taken automatiseren, legacy-systemen moderniseren en IT-landschappen vereenvoudigen met behulp van OutSystems 3 tot 4 keer sneller, waardoor de totale kosten en ecologische voetafdruk afnemen. Door OutSystems te omarmen, kunnen bedrijven hun IT-activiteiten afstemmen op een groenere toekomst, bijdragen aan duurzaamheid en bouwen aan een veerkrachtigere planeet. Inpakken In het tijdperk van digitale transformatie en duurzaamheid is OutSystems een krachtige bondgenoot voor organisaties, die essentiële bedrijfsinnovaties levert, zoals ... High-performance Low-Code ontwikkeling Cloud-native architectuur AI en automatisering Robuuste beveiligingsmaatregelen Samenwerkende DevOps-praktijken Neem de OutSystems-reis om je aan te passen aan IT-trends, uitzonderlijke resultaten te leveren en bij te dragen aan een duurzame en veerkrachtige toekomst. Sta je te popelen om met OutSystems te beginnen? Laat ons helpen
Lees verderContact us
Want to dive deeper into this topic?
Get in touch with our experts today. They are happy to help!
Contact us
Want to dive deeper into this topic?
Get in touch with our experts today. They are happy to help!
Contact us
Want to dive deeper into this topic?
Get in touch with our experts today. They are happy to help!
Contact us
Want to dive deeper into this topic?
Get in touch with our experts today. They are happy to help!