Partner API Authorization Tests voor AI API resellerportals

Een partner API voor resellerportals moet ervan uitgaan dat elke object-ID in een verzoek kan worden gekopieerd, geraden, opnieuw afgespeeld, geregistreerd door een andere integratie of via de verkeerde personeelstool kan worden doorgegeven. Het kernprobleem is niet of klant-ID's ondoorzichtig zijn. Het probleem is of elke actie bewijst dat de beller, het partneraccount, de doeltenant, het object, de property en de goedkeuringsstatus bij elkaar horen.

Dit is het belangrijkst in een AI API resellerportaal omdat de API gewoonlijk objecten op het controlevlak met grote impact blootlegt: downstream-klanten, virtuele API sleutels, portefeuilles, kredietaanpassingen, gebruiksexports, webhookbestemmingen, personeelsgebruikers en noodstops. Met één enkele ontbrekende autorisatiecontrole kan de ene klant het gebruik van een andere klant lezen, een personeelstoken credits tussen tenants laten verplaatsen, of een automatiseringstoken een sleutel laten intrekken die hij nooit zou mogen zien.

Feit: OWASP API Security 2023 vermeldt Broken Object Level Authorization als API1 en Broken Object Property Level Authorization als API3. In praktische termen antwoorden controles op objectniveau: "Kan deze beller op dit object reageren?" terwijl controles op eigendomsniveau antwoorden: "Kan deze beller dit veld instellen of lezen?" Beide zijn eersteklas zorgen voor het ontwerp van Partner API.

Definieer het Authorization contract voordat u tests schrijft

Authorization tests zijn alleen nuttig als ze worden getest op basis van een expliciet beleidscontract. Begin met een matrix die beschrijft welke actor welke actie kan ondernemen op welk doelwit, onder welke omstandigheden. Vertrouw niet op eindpuntnamen of UI-rollen als beleid.

Een nuttige matrix heeft deze kolommen:

• Actortype: partnereigenaar, partnerbeheerder, financiële operator, ondersteuningsoperator, automatiseringstoken, klantbeheerder, klant-alleen-lezen gebruiker.
• Partneraccount: het reseller- of bureauaccount dat eigenaar is van de downstream-klantrelatie.
• Doeltenant: het downstream-klantaccount dat wordt gemaakt, gefactureerd, geïnspecteerd, opgeschort of verwijderd.
• Objecttype: klant, virtuele sleutel, portemonnee, grootboekinvoer, gebruiksrapport, webhook-eindpunt, personeelsgebruiker, prijsprofiel, providertoewijzing.
• Actie: maken, lezen, opsommen, bijwerken, intrekken, opwaarderen, terugbetalen, exporteren, bevriezen, de bevriezing opheffen.
• Monetaire autoriteit: of de actie het saldo, de kredietlimiet, de marge, de betalingsstatus, de factuurstatus of de bestedingslimieten wijzigt.
• Goedkeuringsstatus: of het verzoek vooraf is goedgekeurd, in afwachting van goedkeuring, dubbel goedgekeurd, verlopen of alleen voor noodgevallen is.

Een ondersteuningsmedewerker mag bijvoorbeeld de gemaskeerde sleutelmetadata van een klant bekijken en een sleutel bevriezen tijdens een incident, maar mag geen credits aanmaken, de prijscatalogus wijzigen, volledige gebruiksgegevens exporteren of de sleutel zonder goedkeuring deblokkeren. Een financiële operator kan een kredietaanpassing maken voor een klant die eigendom is van dezelfde partner, maar alleen binnen een geconfigureerd bedrag en alleen nadat er een goedkeuringsrecord bestaat.

Aanbeveling: schrijf de matrix als een versie-artefact en zorg ervoor dat elke autorisatietestnaam verwijst naar een rij of regel. Wanneer een beleid verandert, moet de diff zowel de contractwijziging als de testwijziging tonen.

Gebruik tenantgebonden objectreferenties

Ondoorzichtige ID's verminderen het opsommingsrisico, maar bewijzen geen autorisatie. Een virtuele sleutel-ID, portemonnee-ID, grootboekinvoer-ID, gebruiksexport-ID of cursortoken moet worden omgezet binnen de verwachte partner- en tenantgrens.

Een veilig opzoekpatroon is:

resolve object where
  object.id = request.object_id
  and object.partner_id = actor.partner_id
  and object.customer_id = request.customer_id
  and actor has action_scope for object_type/action
  and object.state allows action

Het gevaarlijke patroon is:

object = find_by_id(request.object_id)
if actor.has_scope("keys:revoke"):
  revoke(object)

De tweede versie autoriseert het bezit van een bereik, niet de autoriteit over het doel. Het mislukt wanneer een geldig token voor Partner A een sleutel-ID van Partner B indient, of wanneer een operator voor Klant A een portemonnee-ID van Klant B indient.

Tenantbinding moet meer omvatten dan de voor de hand liggende objecten. Neem cursortokens op voor gebruiksrapporten, exporttaak-ID's, webhook-eindpunt-ID's, goedkeurings-ID's, idempotentiesleutels en grootboekaanpassings-ID's. Deze objecten voelen vaak 'intern' aan, en dat is precies de reden waarom ze zwakke punten worden.

Bouw een minimale testopstelling voor meerdere huurders

Gebruik een bewust klein armatuur dat het gemakkelijk maakt om verkeerde toegang uit te drukken. Het doel is niet een breed datavolume. Het doel is een duidelijke scheiding.

Partner P1
  Staff: p1_owner, p1_support, p1_finance
  Token: p1_full_token, p1_support_token, p1_finance_token
  Customer C1A
    Key K1A
    Wallet W1A
    Usage cursor U1A
    Ledger entry L1A
  Customer C1B
    Key K1B
    Wallet W1B
    Usage cursor U1B
    Ledger entry L1B

Partner P2
  Staff: p2_owner
  Token: p2_full_token
  Customer C2A
    Key K2A
    Wallet W2A
    Usage cursor U2A
    Ledger entry L2A

Met dit armatuur kun je twee foutklassen testen. Ten eerste, cross-customer-toegang door dezelfde partner, waarbij een beller van P1 C1B probeert aan te raken terwijl hij op C1A reageert. Ten tweede, toegang tussen partners, waarbij een P1-token de objecten van P2 probeert aan te raken.

Aanbeveling: voer hetzelfde programma uit voor de openbare partner API en de backend van de resellerportal. UI-beperkingen beschermen geen directe API clients, achtergrondtaken, browser-devtools of gecompromitteerde integratietokens.

Test objectniveau Authorization op elk eindpunt met grote impact

Maak voor elk eindpunt dat een object-ID accepteert ten minste één positieve test en meerdere negatieve tests. Positieve tests bewijzen dat het armatuur geldig is. Negatieve tests bewijzen dat de grens geldt.

Klanten maken en opzoeken

Het aanmaken van klanten lijkt meestal onschuldig omdat de doeltenant nog niet bestaat. Er is nog steeds autorisatie nodig omdat de beller kan proberen klanten onder een andere partner aan te maken, een verboden prijsprofiel toe te wijzen of interne metadata in te stellen.

Testgevallen:

• Een partnereigenaar kan een klant maken onder dezelfde partner.
• Een automatiseringstoken met klantregistratiebereik kan een klant creëren onder dezelfde partner.
• Een token voor alleen ondersteuning kan geen klant creëren.
• Een P1-token kan geen klant maken met partner_id=P2.
• Een token op klantniveau kan geen broers en zussen vermelden.

Sleutel maken, intrekken en rouleren

Belangrijke levenscyclusacties hebben een grote impact omdat ze runtime-toegang verlenen en de productieworkloads kunnen onderbreken. Beheervlakken van providers maken doorgaans administratieve objecten zoals projecten, werkruimten, serviceaccounts, leden en API sleutels openbaar via API's. Een gateway- of resellerlaag moet met dezelfde zorg omgaan met zijn eigen virtuele sleutels.

Testgevallen:

• P1-automatisering kan alleen K1A voor C1A creëren als het token een sleutelschrijfbereik omvat.
• P1-ondersteuning kan K1A niet maken als de ondersteuningsrol alleen-lezen is voor sleutels.
• P1-ondersteuning kan K1A alleen bevriezen als een noodbevriezing binnen bereik is.
• P1-ondersteuning kan K1B niet intrekken als de verzoekcontext C1A zegt.
• Het volledige P1-token kan K2A niet intrekken.
• Een klantbeheerder voor C1A kan K1B niet roteren, onthullen of intrekken.

Voor teams die Partner API-automatisering implementeren, is de belangrijke test niet alleen 'heeft dit token een key-write?' Het is: 'Heeft dit token een sleutel geschreven voor deze partner, deze klant, deze sleutel, deze status en deze bewerking?'

Tegoed opwaarderen en portemonnee wijzigen

Acties om geld te verplaatsen vereisen strengere tests dan gewone updates. Een opwaardering van tegoed kan syntactisch correct zijn en toch ongeautoriseerd zijn omdat de portemonnee van een andere tenant is, het bedrag de bevoegdheid overschrijdt, de goedkeuringsrecord op een andere klant is gericht of de idempotentiesleutel voor het eerst voor een andere bewerking is gebruikt.

Testgevallen:

• P1-financiering kan na goedkeuring W1A aanvullen binnen de limiet.
• P1-financiering kan W1B niet aanvullen met een goedkeuring die is gemaakt voor W1A.
• P1-financiering kan W2A niet aanvullen.
• P1-ondersteuning kan geen enkele portemonnee opwaarderen.
• Een automatiseringstoken kan de kredietlimiet niet wijzigen tenzij het een expliciet geldverplaatsingsbereik heeft.
• Een opnieuw afgespeelde idempotentiesleutel kan een eerdere W1A-opwaardering niet omleiden naar W1B.

Aanbeveling: behandel idempotentiesleutels als gericht op partner plus bewerking plus doeltenant plus genormaliseerde verzoektekst. Een nieuwe poging moet veilig zijn, maar mag geen conflictkanaal tussen tenants worden.

Gebruiksrapporten en exportcursors

Gebruiksrapporten zijn gemakkelijk te weinig beveiligd omdat ze alleen-lezen zijn. In resellersystemen kunnen gebruiksgegevens klantnamen, werklasten, modelkeuzes, kosten, identificatiegegevens van eindgebruikers en commerciële marges onthullen. Cursor tokens en export-ID's moeten ook tenant-gebonden zijn.

Testgevallen:

• De C1A-beheerder kan C1A-gebruiksbuckets lezen.
• C1A-beheerder kan C1B-gebruik niet lezen door customer_id te wijzigen.
• P1-alleen-lezen analysetoken kan het gebruik voor P1-klanten alleen exporteren als het exportbereik aanwezig is.
• P1-token kan een P2-gebruiksexport niet hervatten met een gekopieerde cursor.
• Een cursor die is gemaakt voor een rapport op sleutelniveau kan niet opnieuw worden gebruikt om gebruik voor de hele tenant op te halen, tenzij dit expliciet is toegestaan.

Als de portal AI API klantgebruiksmeting beschikbaar stelt, test dan zowel de overzichtsweergaven als de downloadbare exports. Exportpaden omzeilen vaak dezelfde controller of beleidscode die door interactieve pagina's wordt gebruikt.

Test op eigenschapsniveau Authorization op PATCH en update eindpunten

Broken Object Property Level Authorization verschijnt wanneer een aanroeper een object mag bijwerken, maar ook velden kan instellen die intern of bevoorrecht moeten zijn of eigendom moeten zijn van een andere workflow.

Voor Partner API's omvatten gevoelige velden vaak:

• partner_id, customer_id en bovenliggende eigendomsvelden.
• provider_project_id, provider_workspace_id en upstream-sleutelreferenties.
• pricing_catalog_version, margin_tier en kortingsoverschrijvingen.
• wallet_balance, credit_limit, settlement_status en factuurstatus.
• fraud_status, risk_score en nalevingsvlaggen.
• role, scopes en vlaggen voor goedkeuring omzeilen.

Gebruik toelatingslijsten, geen weigeringslijsten. Een eindpunt voor het updaten van een klantprofiel kan bijvoorbeeld display_name, billing_email en metadata.external_reference toestaan. Het moet margin_tier, credit_limit en provider_project_id weigeren of negeren, zelfs als de beller het klantobject kan bijwerken.

PATCH /partner/customers/C1A
{
  "display_name": "Acme Support Team",
  "margin_tier": "internal_zero_margin",
  "provider_project_id": "provider-project-owned-by-C1B"
}

Het verwachte resultaat moet deterministisch zijn. Geef de voorkeur aan een validatiefout die niet-toegestane velden identificeert zonder gevoelige interne waarden te onthullen. Accepteer niet stilzwijgend bevoorrechte velden en negeer ze vervolgens, tenzij uw API contract dat patroon al consistent gebruikt.

Maak weigeringen niet-opsomming

Negatieve tests moeten zowel de statuscodes als de antwoordvorm controleren. Als een P1-token om K2A vraagt, mag het antwoord niet onthullen of K2A bestaat onder een andere partner.

Een algemene regel is:

• Gebruik 401 als de beller niet is geverifieerd.
• Gebruik 403 wanneer de aanroeper is geverifieerd, maar geen actiebereik binnen zijn eigen grens heeft.
• Gebruik 404 of een algemeen niet-gevonden antwoord wanneer het object zich buiten de grens van de beller bevindt en het bestaan ervan niet mag worden onthuld.

De exacte conventie kan variëren, maar het gedrag moet consistent zijn. De weigeringsinstantie moet berichten als ‘de sleutel is van een andere klant’ of ‘de portemonnee bestaat onder partner P2’ vermijden. Die informatie is nuttig voor aanvallers en zelden voor legitieme clients.

Afweging: algemene weigeringen maken het opsporen van fouten moeilijker voor partnerontwikkelaars. Los dat op met verzoek-ID's, gestructureerde auditlogboeken en ondersteuningstools, niet door het bestaan van meerdere tenants te lekken in openbare API fouten.

Log de Authorization beslissing, geen gevoelige payloads

Authorization tests moeten ook aantonen dat weigeringen nuttig intern bewijs opleveren. U heeft voldoende details nodig om te reconstrueren wat er tijdens een incident is gebeurd, zonder onbewerkte aanwijzingen, geheimen of onnodige klantgegevens op te slaan.

Logboekvelden moeten het volgende bevatten:

• request_id en traceercorrelatie-ID.
• actor_id, actortype, token-ID en rolsjabloon.
• partner_id van de geverifieerde acteur.
• Doeltenant aangevraagd en doeltenant opgelost, wanneer resolutie is toegestaan.
• Objecttype en actie.
• Beleidsversie en besluitresultaat.
• Redencode voor weigering, zoals missing_scope, tenant_mismatch, approval_required of field_not_allowed.

Log geen volledige API sleutels, upstream providergeheimen, prompts, onbewerkte gebruikspayloads of volledige exportinhoud. Zorg er bij geweigerde cross-tenant-aanvragen voor dat interne logboeken toegangscontrole hebben; de publieke reactie kan algemeen zijn, terwijl het beveiligingsteam nog steeds over voldoende bewijsmateriaal beschikt.

Automatiseer het harnas in CI en staging

Het testharnas moet op drie plaatsen worden uitgevoerd: unit-tests voor beleidsfuncties, integratietests voor API eindpunten en testtests tegen de geïmplementeerde resellerportal-backend. Elke laag vangt verschillende fouten op.

Een praktische CI-structuur:

authz-tests/
  fixtures/
    partners.json
    customers.json
    roles.json
    tokens.json
  matrix/
    keys.yaml
    wallets.yaml
    usage_exports.yaml
    customers.yaml
  tests/
    test_keys_authz.ts
    test_wallet_authz.ts
    test_usage_authz.ts
    test_patch_allowlists.ts

Elke matrixrij moet de actor, het verzoek, de verwachte beslissing en het verwachte niet-opsommingsgedrag definiëren.

- name: p1_support_cannot_revoke_p2_key
  actor: p1_support_token
  method: POST
  path: /partner/customers/C2A/keys/K2A/revoke
  expected_status: 404
  expected_error_code: not_found
  expected_audit_reason: tenant_mismatch

Voeg varianten in mutatiestijl toe die één ID tegelijk omwisselen: klant-ID, sleutel-ID, portemonnee-ID, goedkeurings-ID, cursor, idempotentiesleutel en webhook-eindpunt-ID. Deze tests zijn repetitief van opzet. Herhaling is acceptabel als het bewijst dat elke ID een onafhankelijk bereik heeft.

Operationele checklist

Gebruik deze checklist voordat u een Partner API-eindpunt verzendt:

• Het eindpunt heeft een benoemde autorisatieregel in de beleidsmatrix.
• Elke objectzoekopdracht bevat randvoorwaarden voor partners en tenants.
• Elk lijsteindpunt wordt vóór paginering gefilterd op actorgrens.
• Elke cursor, export-ID, webhook-ID, goedkeurings-ID en idempotentiesleutel heeft een bereik.
• PATCH-eindpunten gebruiken toelatingslijsten voor eigenschappen per rol en actie.
• Acties om geld te verplaatsen vereisen een expliciete reikwijdte en goedkeuringsstatus.
• Noodbevriezing is gescheiden van bevriezing en kredietautoriteit.
• Weigeringen voorkomen lekken tussen verschillende tenants.
• Auditlogboeken registreren de autorisatiebeslissing en de beleidsversie.
• Dezelfde negatieve tests worden uitgevoerd tegen API en portal-backend-paden.

Afwegingen om expliciet te beslissen

Fijnkorrelige scopes verkleinen de straal, maar vergroten de complexiteit van de onboarding van partners. Standaard rolsjablonen helpen: eigenaar, financiën, ondersteuning, analyse, automatisering van de inrichting en reactie op noodsituaties. Laat geavanceerde partners deze sjablonen aanpassen in plaats van te beginnen met ruwe scopes.

Strikte toelatingslijsten voor eigenschappen vertragen de uitrol van functies omdat voor elk nieuw bewerkbaar veld een beleidswijziging nodig is. Die wrijving is nuttig op het gebied van facturering, prijzen, providertoewijzing en sleutelbeheer. Voor velden met een laag risicoprofiel kan het proces lichter zijn.

Goedkeuringsstromen verminderen onbedoelde of kwaadwillige kredietwijzigingen, maar voegen vertraging toe aan legitieme ondersteuningsactiviteiten. Houd noodbevriezing snel, omkeerbaar en afzonderlijk geregeld. Laat niet hetzelfde noodtoken credits toevoegen, marges wijzigen, gebruik exporteren en accounts deblokkeren.

Voorspelling: resellerportals zullen steeds meer administratieve acties via Partner API's blootleggen, omdat klanten selfservice-levering, rapportage en automatisering verwachten. De systemen die goed verouderen zijn de systemen met autorisatiecontracten en negatieve tests, en niet de systemen die alleen afhankelijk zijn van routenamen, verborgen UI-controles of ondoorzichtige ID's.

Conclusie waar actie op ondernomen kan worden

Bouw het autorisatieharnas op voordat de partner API groot genoeg wordt zodat elk eindpunt zijn eigen uitzondering heeft. Begin met twee partners, twee klanten onder één partner, één klant onder een andere partner en een kleine set tokens. Test vervolgens de acties die u het meest schade kunnen berokkenen: het maken van sleutels, het intrekken van sleutels, het opwaarderen van tegoeden, het exporteren van gebruik, updates van portemonnees, hergebruik van goedkeuring, opnieuw afspelen van idempotentie en PATCH-velden.

Het contract is eenvoudig uit te leggen: een beller moet het juiste bereik hebben, onder de juiste partner, voor de juiste huurder, object, eigendom, actie, bedrag en goedkeuringsstatus. Het implementatiewerk zorgt ervoor dat dit op elk eindpunt waar wordt gemaakt, ook op de saaie.

Gerelateerde informatie

• idempotente Partner API-automatisering voor het inrichten van sleutels en tegoeden