Hatókörök

Zárt halmaz, resource:action formában. Elég kicsi ahhoz, hogy egy embernek jelölőnégyzet-listán megmutassuk, és elég stabil ahhoz, hogy egy tárolt hozzáférés egy év múlva is ugyanazt jelentse. Ugyanebben a szókészletben íródnak a munkaterületi SZEREPKÖRÖK, és ez szabályozza az MCP eszközöket is, így egy csak olvasási jogú kliens egy küldő eszközt még látni sem lát. Egy ábécé, három felület.

Egy kulcs kiadható egy SZEREPKÖRRE, és a szerepkör nem második jogosultságcsomag, hanem felső korlát. Amit a kulcs ténylegesen megtehet, az a saját hatóköreinek és az adott szerepkör jogosultságainak a METSZETE (key.scopes ∩ role.permissions), amelyet a rendszer minden kérésnél egyszer, a határon, még bármelyik végpont elérése előtt kiszámít. A lánc további részében semmi nem tud a szerepkörök létezéséről: egy olyan hatókör, amellyel a szerepkör nem rendelkezik, egyszerűen nincs benne abban a listában, amelyet a hatókör-ellenőrzések olvasnak.

A két listát tehát együtt kell olvasni, és önmagában egyik sem dönt. Az a kulcs, amely emails:send joggal rendelkezik, de olyan szerepkör alatt áll, amely nem, nem küldhet; az a szerepkör pedig, amely rendelkezik az emails:send joggal, semmit nem ad annak a kulcsnak, amely soha nem kérte. Egy hatókör bejelölése jogosultság kérése, és a szerepkör dönti el, hogy a kértből mennyit kapsz meg.

A metszet kérésenként dől el, nem pedig a kiadáskor íródik rá a kulcsra. Ettől lesz egy szerepkör szűkítése azonnali visszavonás, amely a hívó következő hívásánál már érvényben van, a kulcs cseréje nélkül – és ugyanígy azonnali a bővítése is, ami a fontosabbik fele.

A GET /ping és a GET /keys/self a grantedScopes és a roleId mellett a scopes mezőt is visszaadja, elsősorban egyetlen hibaeset miatt. A scopes a tényleges lista, és egyedül ez jogosít fel bármire; a grantedScopes az, amivel a kulcsot kiadták. Ami a másodikban szerepel, de az elsőből hiányzik, azt a szerepkör vette el, és ez a különbség a teljes válasz arra, hogy „a kulcsomon rajta van az emails:send, mégis insufficient_scope hibát kapok”. A megoldás a szerepkör módosítása, nem egy újabb kulcs.

curl "$OE/ping" -H "$AUTH" {  "ok": true,  "keyId": "4c1b257a66287fd113bd89d0",  "mode": "live",  "scopes": ["emails:read", "threads:read"],  "roleId": "role_c40a95f21cc65d31c2a89e07",  "grantedScopes": ["emails:send", "emails:read", "threads:read"],  "workspaceId": "10417196-e324-4283-af98-66ec62167c47"}

A hatóköröktől függetlenül a kulcs abban is szűkíthető, hogy milyen néven küldhet. Két listát hordoz. A domainAllowlist teljes domaineket tartalmaz, és az a kulcs, amely egy domaint birtokol, bármelyik rajta lévő címről küldhet, beleértve a kulcs létrehozása után létrejött címeket is. Az addressAllowlist egyedi címeket tartalmaz. Ha mindkettőt üresen hagyod, a kulcs olyan széles, mint a munkaterület – szélesebb soha. A GET /keys/self mindkét listát megmutatja, a GET /addresses pedig azt jelenti, hogy egy adott kulcs ténylegesen mit használhat, és ez a válasz a megmagyarázhatatlan from_address_forbidden hibákra.

Ugyanez a beállítás szűkíti azt is, amit a kulcs olvashat. Az elküldött levelek, a követés és a naptár csak azokra a címekre válaszol, amelyek nevében a kulcs küldhet, így egy domainre korlátozott kulcs sem küldeni, sem olvasni nem tud egy másik nevében. A teljes domain azt is lehetővé teszi, hogy a kulcs beállítsa az adott domain követési hosztját, amire az egyedi címekre korlátozott kulcs nem képes.

Három szűkítés van tehát, és ezek nem felülírják, hanem egymásra rakódnak: a kulcs hatókörei, a fölötte álló szerepkör jogosultságai, valamint azok a domainek és címek, amelyeket From fejlécbe tehet. Egy küldéshez mind a három kell, és az elutasítás csak az elsőt nevezi meg, amelybe belefutott.