Authenticatie en tokenbevoegdheden

Twee manieren om te authenticeren

Beveiligde klantendpoints gebruiken auth:sanctum. Een request kan een persoonlijk toegangstoken meesturen via Authorization: Bearer ..., of een ondersteunde first-party sessie gebruiken. Core schakelt daarvoor de stateful API-middleware van Sanctum in. Schrijfverzoeken via een sessie hebben nog steeds de juiste CSRF-beveiliging nodig. De bearer-voorbeelden vervangen de browserlogin niet.

Tokenbevoegdheden en medewerkersrechten zijn verschillende systemen. Met orders.read leest een token de bestellingen van de huidige klant, niet alle bestellingen van de winkel. /api/v1 is geen Admin-CRUD-API. De accountresource geeft het klant-ID terug; dat is niet noodzakelijk het ID van het onderliggende gebruikersaccount.

Bronnen: API-routes, middlewareconfiguratie en AccountResource.

Maak een herkenbaar token

POST /api/v1/auth/tokens accepteert JSON:

Zonder abilities krijgt het token ['*']. Geef dus altijd expliciet de minimaal benodigde rechten op. Een lege array betekent niet de standaardselectie: dat levert een token zonder routebevoegdheden op. Zodra * is opgenomen, wordt de selectie genormaliseerd naar volledige toegang.

Voorbeeld van token-request.json, met fictieve inloggegevens:

{
  "email": "[email protected]",
  "password": "<account-password>",
  "name": "Bestellingen van klant lezen",
  "abilities": ["account.read", "orders.read", "tokens.revoke"]
}

curl --request POST 'https://shop.example.test/api/v1/auth/tokens' \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json' \
  --data-binary @token-request.json

De 201-response heeft geen data-omhulling:

{
  "token": "<plain-text-token>",
  "token_type": "Bearer",
  "name": "Bestellingen van klant lezen"
}

Bewaar het ontvangen token veilig. Commit het requestbestand, de response en ingevulde shellgeschiedenis niet. Alleen bij het aanmaken retourneert de controller het leesbare token. Deze routes bieden geen uitwisseling met refreshtokens.

De controller zoekt het e-mailadres in kleine letters op, controleert de wachtwoordhash en weigert geanonimiseerde gebruikers. Onjuiste inloggegevens geven 422 validation_error, niet 401. Het endpoint controleert alleen e-mail en wachtwoord. Het accepteert geen tweefactorcode, expires_at of IP-lijst. Ga er dus niet van uit dat de tweefactorcontrole van de beheerlogin ook hier wordt toegepast.

Bron: TokenController.

Beschikbare bevoegdheden

De underscores in credit_notes.read, digital_secrets.read en event_tickets.read horen bij de namen. De bijbehorende URL's gebruiken koppeltekens.

EnsureApiTokenAbility controleert bevoegdheden als het request een bearer-token bevat. Persoonlijke tokenscopes worden niet op een verzoek met alleen sessieauthenticatie toegepast. Een ontbrekend recht geeft 403 insufficient_scope met errors.required_ability. Een onbekend routenaamprefix voor een Module wordt geweigerd als unmapped_api_route. Een nieuwe ability in een package declareren voegt die niet vanzelf aan de Core-catalogus toe.

Gebruik en intrekken

Nadat je AGOVENA_TOKEN veilig in de omgeving hebt geplaatst:

curl 'https://shop.example.test/api/v1/me' \
  --header 'Accept: application/json' \
  --header "Authorization: Bearer $AGOVENA_TOKEN"

curl --request DELETE 'https://shop.example.test/api/v1/auth/tokens' \
  --header 'Accept: application/json' \
  --header "Authorization: Bearer $AGOVENA_TOKEN"

Intrekken vereist tokens.revoke of *. De response is 200 {"ok":true} en alleen het huidige persoonlijke token wordt verwijderd. Dit verwijdert niet alle tokens en logt geen browsersessie uit. Bij sessieauthenticatie zonder persoonlijk token retourneert de controller eveneens ok, zonder een token te verwijderen.

IP-beleid en snelheidslimieten

De Admin-tokeneditor ondersteunt een IP-beleid per token. Een lege lijst staat ieder IP toe. Het wachtwoordendpoint maakt expliciet een lege lijst aan. Stel beperkingen in via het tokenbeheerscherm in plaats van een niet-gedocumenteerd API-veld mee te sturen. Een geweigerd bronadres krijgt 403 ip_not_allowed.

Vertrouwde proxies bepalen welk bronadres de applicatie ziet. Core accepteert expliciet ingestelde TRUSTED_PROXIES, maar geen wildcardvertrouwen. Controleer de proxyketen van je deployment voordat je op een IP-lijst vertrouwt.

Tokenaanmaak is beperkt tot vijf verzoeken per minuut per combinatie van IP en e-mailadres. Daarnaast registreert een accountgebonden controle mislukte wachtwoordpogingen en blokkeert deze na tien fouten binnen het venster van 600 seconden. Gewone beveiligde requests hebben een limiet van 60 per minuut per gebruiker of IP; checkout en betaalinitiatie gebruiken 10. De openbare catalogus gebruikt 120 per minuut per IP.

Behoud deze integratietests

Test bearer-authenticatie en sessieauthenticatie afzonderlijk. Controleer ontbrekende rechten, onbekende abilities, intrekken zonder bevoegdheid, object-ID's van andere klanten, geblokkeerde IP's en het weglaten van abilities. Log tijdens fouttests geen requests met inloggegevens.

Relevante bronnen zijn ApiTokenManagementTest, StorefrontApiTest, ApiTokenAbilities en AppServiceProvider. Ga verder met de endpointreferentie.