Det kunden skal kunne forstå
Autorisationen viser appnavn, udgiver og det formål, apprevisionen blev gennemgået til. Kunden skal kunne se forskellen på at forberede en postering, bogføre den og læse organisationens eksisterende regnskabsdata. Tekniske scopes har derfor forklarende labels, ikke blot en lang streng med kolonadskilte navne.
Appens ønskede scopes er et maksimum for ansøgningen. Review kan afgrænse dem, og kunden kan vælge et yderligere afgrænset udsnit. Appen må ikke senere udvide grantet ved at sende flere scopes i et token- eller domænekald.
Hvem der må autorisere
Autorisation gives af organisationsejeren og kræver en aktuel ejerrelation i den valgte, aktive organisation og en tofaktorbekræftet session (AAL2). Den højeste rolle i en anden organisation giver ikke ret til at autorisere den aktuelle virksomhed.
En medarbejder, der blot kan se regnskabet, må ikke tilslutte en app med endelig bogføring. En intern Hours-reviewer kan heller ikke acceptere på kundens vegne gennem reviewknappen. De to beslutninger gemmes som forskellige relationer med forskellige aktører.
Vælg organisation og kontireferencer
Kunden vælger én organisation i autorisationsflowet. Appen sender ikke et frit organisations-ID i hver efterfølgende payload. Det modtagne token bindes til den gemte grant, så et ændret requestfelt ikke kan flytte handlingen til en anden juridisk enhed.
Kunden vælger også de kontireferencer, appen må bruge. Der kan vælges højst 200. Dette valg begrænser konfigurationsopslag og bogføringsreferencer, og GET /journal returnerer kun linjer på disse konti. Det er ikke adgang til bankkonti eller en kontosaldo.
Udløb og særskilt bogføringsmandat
Granten har en eksplicit gyldighed mellem 1 og 90 dage. Et access-token har kortere levetid og kan ikke gøre grantet længere. Rotation af refresh-token forlænger heller ikke en tilbagekaldt eller udløbet kundetilladelse.
Hvis journal:post vælges, skal kunden særskilt bekræfte bogføringsmandatet. Uden denne bekræftelse accepteres grantet ikke med endelig bogføring. Et tidligere prepare-kald eller en succesfuld sandboxprøve er ikke et alternativ til mandatet.
OAuth-forløbet
Appen starter authorization-code-flowet med præcis redirectadresse, state, S256-challenge og den publicerede resource. Serveren gemmer requesten. Kunden ser denne serverregistrering, ikke en efterfølgende omskrevet payload fra appen.
Ved godkendelse returneres en engangskode, som gælder 60 sekunder, til den godkendte callback. Appen veksler den med sin verifier og den relevante klientautentifikation. Ved afvisning får appen en autorisationsafvisning, ikke et begrænset token “for en sikkerheds skyld”. Se autentifikation.
Efter tilslutning
Hvert produktionskald genkontrollerer apprevision, grant, organisation og de aktuelle adgangsbetingelser. Et gyldigt token er ikke en permanent delegation uafhængig af, om den autoriserende ejer senere suspenderes eller fjernes.
Kunden kan tilbagekalde forbindelsen. Nye kald stopper, og endnu ikke afsendte leveringer fortsætter ikke under en ugyldig grant. Data, som allerede er sendt til appen, bliver ikke automatisk slettet hos modtageren; partnerens slette- og retentionproces er et særskilt ansvar.
Hvad kunden ikke tilslutter
Flowet giver ikke dokumentadgang i Audit Center, adgang til alle selskaber i en kæde, banktransaktioner, generel filupload eller automatisk betalingsinitiering. Disse områder er ikke implicitte dele af ordet “integration”.
Før produktionsbrug bør hele flowet prøves med reelle testidentiteter i et isoleret miljø: ejer, almindeligt medlem, suspenderet ejer, forkert organisation, afvist samtykke, udløbet request, genbrugt kode og tilbagekaldelse. En formular, der ser rigtig ud, beviser ikke denne adgangsadfærd.