Partner API Authorization Tests for AI API forhandlerportaler

En partner API til forhandlerportaler skal antage, at hvert objekt-id i en anmodning kan kopieres, gættes, afspilles igen, logges af en anden integration eller sendes gennem det forkerte personaleværktøj. Kerneproblemet er ikke, om kunde-id'er er uigennemsigtige. Problemet er, om hver handling beviser, at opkalderen, partnerkontoen, mållejer, objekt, ejendom og godkendelsestilstand hører sammen.

Dette betyder mest i en AI API-forhandlerportal, fordi API normalt afslører kontrolplanobjekter med stor indflydelse: downstream-kunder, virtuelle API nøgler, tegnebøger, kreditjusteringer, brugseksport, webhook-destinationer, personalebrugere og nødstop. En enkelt manglende godkendelseskontrol kan lade en kunde læse en anden kundes brug, lade et personaletoken flytte kreditter på tværs af lejere eller lade et automatiseringstoken tilbagekalde en nøgle, den aldrig burde se.

Fakta: OWASP API Security 2023 viser Broken Object Level Authorization som API1 og Broken Object Property Level Authorization som API3. Rent praktisk svarer kontrol på objektniveau "kan denne opkalder handle på dette objekt?" mens kontrol på ejendomsniveau svarer "kan denne opkalder indstille eller læse dette felt?" Begge er førsteklasses bekymringer for Partner API design.

Definer Authorization-kontrakten før du skriver test

Authorization test er kun nyttige, hvis de tester i forhold til en eksplicit politikkontrakt. Start med en matrix, der beskriver, hvilken aktør der kan udføre hvilken handling på hvilket mål, under hvilke forhold. Stol ikke på slutpunktsnavne eller UI-roller som politikken.

En nyttig matrix har disse kolonner:

• Aktørtype: partnerejer, partneradministrator, finansoperatør, supportoperatør, automatiseringstoken, kundeadministrator, kunde-skrivebeskyttet bruger.
• Partnerkonto: forhandler- eller bureaukontoen, der ejer downstreamkundeforholdet.
• Mållejer: den downstream-kundekonto, der oprettes, faktureres, inspiceres, suspenderes eller slettes.
• Objekttype: kunde, virtuel nøgle, tegnebog, finanspostering, brugsrapport, webhook-slutpunkt, personalebruger, prisprofil, udbyderkortlægning.
• Handling: oprette, læse, liste, opdatere, tilbagekalde, fylde op, refundere, eksportere, fryse, ophæve.
• Monetær myndighed: om handlingen ændrer saldo, kreditgrænse, margin, afregningsstatus, fakturastatus eller forbrugsloft.
• Godkendelsestilstand: om anmodningen er forhåndsgodkendt, afventer godkendelse, dobbeltgodkendt, udløbet eller kun for nødsituationer.

For eksempel kan en supportoperatør have tilladelse til at se en kundes maskerede nøglemetadata og fryse en nøgle under en hændelse, men ikke oprette kreditter, ændre priskataloget, eksportere fuld brugsdata eller frigøre nøglen uden godkendelse. En finansoperatør kan oprette en kreditjustering for en kunde, der ejes af den samme partner, men kun inden for et konfigureret beløb og først efter, at der findes en godkendelsespost.

Anbefaling: skriv matrixen som en versioneret artefakt, og lad derefter hvert autorisationstestnavn henvise til en række eller regel. Når en politik ændres, skal forskellen vise både kontraktændringen og testændringen.

Use Tenant-Bound Object References

Uigennemsigtige id'er reducerer opregningsrisikoen, men de beviser ikke autorisation. Et virtuel nøgle-id, tegnebogs-id, finanspost-id, brugseksport-id eller markørtoken skal løses inden for den forventede partner- og lejergrænse.

Et sikkert opslagsmønster er:

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

Det farlige mønster er:

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

Den anden version tillader besiddelse af et omfang, ikke autoritet over målet. Det mislykkes, når et gyldigt token for partner A indsender et nøgle-id fra partner B, eller når en operatør for kunde A indsender et tegnebogs-id fra kunde B.

Lejerbinding bør dække mere end de åbenlyse genstande. Inkluder markør-tokens til brugsrapporter, eksportjob-id'er, webhook-slutpunkt-id'er, godkendelses-id'er, idempotensnøgler og finansjusterings-id'er. Disse objekter føles ofte "interne", og det er netop derfor, de bliver svage punkter.

Byg en minimal testopstilling for flere lejere

Brug en bevidst lille armatur, der gør forkert adgang let at udtrykke. Målet er ikke en bred datamængde. Målet er klar adskillelse.

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

Dette program giver dig mulighed for at teste to fejlklasser. Først den samme partner på tværs af kunder, hvor en opkalder fra P1 forsøger at røre ved C1B, mens han handler på C1A. For det andet adgang på tværs af partnere, hvor et P1-token forsøger at røre ved P2s objekter.

Anbefaling: køre den samme kamp mod den offentlige partner API og forhandlerportalens backend. Brugergrænsefladebegrænsninger beskytter ikke direkte API klienter, baggrundsjob, browserudviklingsværktøjer eller kompromitterede integrationstokens.

Test objektniveau Authorization på hvert effektfuldt slutpunkt

For hvert slutpunkt, der accepterer et objekt-id, skal du oprette mindst én positiv test og flere negative tests. Positive tests beviser, at armaturet er gyldigt. Negative test beviser, at grænsen holder.

Kundeoprettelse og opslag

Kundeoprettelse ser normalt harmløs ud, fordi mållejeren ikke eksisterer endnu. Det kræver stadig godkendelse, fordi den, der ringer op, kan forsøge at oprette kunder under en anden partner, tildele en forbudt prisprofil eller indstille interne metadata.

Testcases:

• En partnerejer kan oprette en kunde under den samme partner.
• Et automatiseringstoken med kundeprovisioneringsomfang kan oprette en kunde under den samme partner.
• Et support-token kan ikke oprette en kunde.
• Et P1-token kan ikke oprette en kunde med partner_id=P2.
• Et token på kundeniveau kan ikke angive søskendekunder.

Oprettelse, tilbagekaldelse og rotation af nøgle

Nøglelivscyklushandlinger har stor indflydelse, fordi de giver runtime-adgang og kan afbryde produktionsarbejdsbelastninger. Udbyderkontrolplaner afslører almindeligvis administrative objekter såsom projekter, arbejdsområder, servicekonti, medlemmer og API nøgler gennem API'er. Et gateway- eller forhandlerlag bør behandle sine egne virtuelle nøgler med samme omhu.

Testcases:

• P1-automatisering kan kun oprette K1A for C1A, når dets token inkluderer nøgleskrivningsomfang.
• P1-support kan ikke oprette K1A, hvis supportrollen er skrivebeskyttet for nøgler.
• P1-understøttelse kan kun fryse K1A, hvis nødfrysning er omfattet.
• P1-understøttelse kan ikke tilbagekalde K1B, når anmodningskonteksten siger C1A.
• P1 fuld token kan ikke tilbagekalde K2A.
• En kundeadministrator for C1A kan ikke rotere, afsløre eller tilbagekalde K1B.

For teams, der implementerer Partner API automation, er den vigtige test ikke kun "har dette token nøgleskrivning?" Det er "har dette token nøgleskrivning for denne partner, denne kunde, denne nøgle, denne tilstand og denne operation?"

Kreditopfyldninger og ændringer i tegnebogen

Handlinger til at flytte penge kræver strengere test end almindelige opdateringer. En kreditpåfyldning kan være korrekt syntaktisk og stadig være uautoriseret, fordi tegnebogen tilhører en anden lejer, beløbet overstiger autoriteten, godkendelsesposten er målrettet mod en anden kunde, eller idempotensnøglen først blev brugt til en anden operation.

Testcases:

• P1 finance kan efter godkendelse fylde W1A op inden for beløbsgrænsen.
• P1 finance kan ikke fylde W1B op ved at bruge en godkendelse oprettet til W1A.
• P1-finansiering kan ikke supplere W2A.
• P1-understøttelse kan ikke fylde nogen tegnebog op.
• Et automatiseringstoken kan ikke ændre kreditgrænsen, medmindre det har et eksplicit anvendelsesområde til at flytte penge.
• En genafspillet idempotensnøgle kan ikke omdirigere en tidligere W1A-top-up til W1B.

Anbefaling: behandle idempotensnøgler som omfattet af partner plus drift plus mållejer plus normaliseret anmodningstekst. Et genforsøg bør være sikkert, men det bør ikke blive en kollisionskanal på tværs af lejere.

Brugsrapporter og eksportmarkører

Brugsrapporter er nemme at underbeskytte, fordi de er skrivebeskyttede. I forhandlersystemer kan brugsdata afsløre kundenavne, arbejdsbelastninger, modelvalg, omkostninger, slutbruger-id'er og kommercielle marginer. Cursor tokens og eksport-id'er skal også være lejerbundne.

Testcases:

• C1A-administrator kan læse C1A-brugssamlinger.
• C1A-administrator kan ikke læse C1B-brug ved at ændre customer_id.
• P1-skrivebeskyttet analysetoken kan kun eksportere brug for P1-kunder, hvis eksportomfang er til stede.
• P1-token kan ikke genoptage en P2-brugseksport med en kopieret markør.
• En markør, der er oprettet til en rapport på nøgleniveau, kan ikke genbruges til at hente brug for hele lejeren, medmindre det er udtrykkeligt tilladt.

Hvis portalen afslører AI API kundeforbrugsmåling, test både oversigtsvisningerne og de eksporter, der kan downloades. Eksportstier omgår ofte den samme controller eller politikkode, der bruges af interaktive sider.

Test ejendomsniveau Authorization på PATCH og opdater slutpunkter

Broken Object Property Level Authorization vises, når en opkalder har tilladelse til at opdatere et objekt, men kan også angive felter, der skal være interne, privilegerede eller ejes af en anden workflow.

For Partner API'er omfatter følsomme felter ofte:

• partner_id, customer_id og forældreejerskabsfelter.
• provider_project_id, provider_workspace_id og opstrøms nøglereferencer.
• pricing_catalog_version, margin_tier og rabattilsidesættelser.
• wallet_balance, credit_limit, settlement_status og fakturastatus.
• fraud_status, risk_score og overholdelsesflag.
• role, scopes og godkendelsesomgår flag.

Brug tilladelseslister, ikke afvisningslister. For eksempel kan et slutpunkt for opdatering af kundeprofil tillade display_name, billing_email og metadata.external_reference. Den bør afvise eller ignorere margin_tier, credit_limit og provider_project_id, selvom den, der ringer, kan opdatere kundeobjektet.

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

Det forventede resultat bør være deterministisk. Foretrækker en valideringsfejl, der identificerer ikke-tilladte felter uden at afsløre følsomme interne værdier. Accepter ikke privilegerede felter uden lyd og ignorer dem, medmindre din API-kontrakt allerede bruger dette mønster konsekvent.

Make Denials Non-numerating

Negative test bør kontrollere både statuskoder og svarform. Hvis et P1-token anmoder om K2A, bør svaret ikke afsløre, om K2A eksisterer under en anden partner.

En almindelig regel er:

• Brug 401, når den, der ringer, ikke er godkendt.
• Brug 403, når den, der ringer, er godkendt, men mangler et handlingsområde i sin egen grænse.
• Brug 404 eller et generisk ikke-fundet svar, når objektet er uden for den kaldendes grænse, og eksistensen ikke bør afsløres.

Den nøjagtige konvention kan variere, men adfærden skal være konsekvent. Nægtelsesorganet bør undgå beskeder som "nøglen tilhører en anden kunde" eller "pungen findes under partner P2." Disse oplysninger er nyttige for angribere og sjældent nyttige for legitime kunder.

Trade-off: generiske afslag gør fejlfinding sværere for partnerudviklere. Løs det med anmodnings-id'er, strukturerede revisionslogfiler og supportværktøjer, ikke ved at lække eksistens på tværs af lejere i offentlige API fejl.

Log Authorization-beslutningen, ikke-følsomme nyttelast

Authorization test bør også hævde, at afslag frembringer nyttige interne beviser. Du har brug for nok detaljer til at rekonstruere, hvad der skete under en hændelse uden at gemme rå prompts, hemmeligheder eller unødvendige kundedata.

Logfelter skal indeholde:

• request_id og spor korrelations-id.
• actor_id, skuespillertype, token-id og rolleskabelon.
• partner_id fra den godkendte skuespiller.
• Anmodet mållejer og løst mållejer, når løsning er tilladt.
• Objekttype og handling.
• Politikversion og beslutningsresultat.
• Nægtelsesårsagskode, såsom missing_scope, tenant_mismatch, approval_required eller field_not_allowed.

Log ikke fulde API-nøgler, upstream-udbyderhemmeligheder, prompter, råforbrugsnyttelast eller fuldt eksportindhold. Ved afviste anmodninger om krydslejere skal du passe på, at interne logfiler er adgangskontrollerede; det offentlige svar kan være generisk, mens sikkerhedsteamet stadig har nok beviser.

Automatiser selen i CI og Staging

Testselen skal køre tre steder: enhedstests for politikfunktioner, integrationstests for API-slutpunkter og iscenesættelsesprober mod den installerede forhandlerportal-backend. Hvert lag fanger forskellige fejl.

En praktisk CI-struktur:

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

Hver matrixrække skal definere aktør, anmodning, forventet beslutning og forventet ikke-optællingsadfærd.

- 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

Tilføj varianter i mutationsstil, der udskifter én identifikator ad gangen: kunde-id, nøgle-id, tegnebogs-id, godkendelses-id, markør, idempotensnøgle og webhook-endepunkt-id. Disse tests er gentagne af design. Gentagelse er acceptabel, når det beviser, at hver identifikator er uafhængigt omfang.

Driftstjekliste

Før du sender et Partner API-slutpunkt, skal du bruge denne tjekliste:

• Endepunktet har en navngivet autorisationsregel i politikmatricen.
• Hvert objektopslag inkluderer partner- og lejergrænsebetingelser.
• Hver listeslutpunkt filtreres efter aktørgrænse før paginering.
• Hver markør, eksport-id, webhook-id, godkendelses-id og idempotensnøgle er omfattet.
• PATCH-endepunkter bruger egenskabstilladelseslister efter rolle og handling.
• Handlinger til at flytte penge kræver eksplicit omfang og godkendelsesstatus.
• Nødfrysning er adskilt fra unfreeze og kreditmyndighed.
• Afvisninger undgår eksistenslækager på tværs af lejere.
• Revisionslogfiler registrerer godkendelsesbeslutningen og politikversionen.
• De samme negative tests kører mod API og portal backend-stier.

Trade-offs to Decide Eksplicit

Finkornede scopes reducerer sprængningsradius, men de øger partner-onboarding-kompleksiteten. Standardrolleskabeloner hjælper: ejer, økonomi, support, analyser, klargøringsautomatisering og nødberedskab. Lad avancerede partnere tilpasse sig fra disse skabeloner i stedet for at starte fra rå scopes.

Strenge egenskabstilladelseslister sænker udrulningen af funktioner, fordi hvert nyt redigerbart felt skal ændres. Denne friktion er nyttig til fakturering, prissætning, udbyderkortlægning og nøglestyringsfelter. For felter med lavrisikoprofiler kan processen være lettere.

Godkendelsesstrømme reducerer utilsigtede eller ondsindede kreditændringer, men de tilføjer forsinkelse til legitime supportoperationer. Hold nødfrysning hurtig, reversibel og separat scoped. Lad ikke det samme nødsymbol tilføje kreditter, ændre marginer, eksportere brug og frigøre konti.

Forudsigelse: forhandlerportaler vil blive ved med at afsløre flere administrative handlinger gennem partner-API'er, fordi kunderne forventer selvbetjeningslevering, rapportering og automatisering. De systemer, der ældes godt, vil være dem med autorisationskontrakter og negative tests, ikke dem, der er afhængige af rutenavngivning, skjulte UI-kontroller eller uigennemsigtige id'er alene.

Handlingsbar konklusion

Byg godkendelsesselen, før partner API bliver stor nok til, at hvert slutpunkt har sin egen undtagelse. Start med to partnere, to kunder under en partner, en kunde under en anden partner og et lille sæt tokens. Test derefter de handlinger, der kan skade dig mest: nøgleoprettelse, nøgletilbagekaldelse, kreditopfyldning, brugseksport, tegnebogsopdateringer, godkendelsesgenbrug, idempotensafspilning og PATCH-felter.

Kontrakten er enkel at angive: En opkalder skal have det rigtige omfang, under den rigtige partner, for den rigtige lejer, objekt, ejendom, handling, beløb og godkendelsestilstand. Implementeringsarbejdet gør det sandt på alle endpoints, inklusive de kedelige.

Relateret læsning

• idempotent Partner API automation for provisioning keys and credits