OAuth është i dobishëm, por Google dhe Microsoft e kthejnë në portë kontrolli

OAuth është një përmirësim sigurie

Largimi nga Basic Authentication, fjalëkalimet afatgjata dhe kredencialet me privilegje të gjera ishte vendimi i duhur. OAuth mundëson leje të kufizuara, tokenë qasjeje jetëshkurtër, lidhje të revokueshme dhe kontroll më të mirë mbi atë që një aplikacion mund të bëjë realisht.

Standardi është i hapur. Ai shpjegon si një aplikacion mund të kërkojë dhe të marrë qasje në emër të një përdoruesi. Nuk u kërkon vetë zhvilluesve të dorëzojnë dokumente biznesi, prova organizative, video demonstruese ose një kërkesë pranimi te operatori i platformës. Kjo shtresë shtesë vjen nga rregullat e ekosistemit.

Një standard i hapur mund të kthehet sërish në një portë të mbyllur

SMTP dhe IMAP lindën në një internet të ndërtuar rreth ndërveprueshmërisë. Një ofrues mund të operonte një server emaili, një zhvillues mund të ndërtonte një klient dhe të dy mund të komunikonin përmes standardeve të dokumentuara.

OAuth nuk e shkatërron këtë hapje. Por kur qasja në kutinë postare varet gjithashtu nga miratimi i pronarit të platformës, pyetja vendimtare ndryshon: a e autorizon përdoruesi aplikacionin, apo Google ose Microsoft vendos nëse ai aplikacion mund të autorizohet fare?

Një shqyrtim sigurie i kërkon aplikacionit të demonstrojë trajtim të sigurt dhe të kufizuar sipas qëllimit të të dhënave të përdoruesit. Kontrolli i hyrjes në ekosistem, në vend të kësaj, i kërkon vazhdimisht publikuesit të justifikojë pse aplikacioni mund të ekzistojë aty. Ky artikull argumenton se dallimi ka rëndësi, duke pranuar njëkohësisht ndjeshmërinë e të dhënave të kutive postare.

Microsoft 365: pëlqimi shpesh ndalet te kufiri i organizatës

Pengesa e Microsoft e përshkruar këtu shpesh nuk është një shqyrtim videoje si ai i Google. Është ndërveprimi midis Microsoft Entra ID, verifikimit të publikuesit, pëlqimit të administratorit dhe politikave të çdo organizate Microsoft 365.

Microsoft rekomandon kufizimin e pëlqimit të përdoruesve te publikuesit e verifikuar dhe lejet e zgjedhura të klasifikuara me rrezik të ulët. Administratorët mund ta kufizojnë më tej ose ta çaktivizojnë. Një përdorues mund ta dëshirojë shprehimisht një integrim të kutisë postare dhe megjithatë t'i thuhet se kërkohet miratimi i administratorit.

Verifikimi i publikuesit mund të jetë vendimtar edhe për aplikacione të reja që u shërbejnë disa organizatave. Ndër kërkesat e tjera, publikuesi ka nevojë për një llogari të verifikuar Microsoft AI Cloud Partner Program të lidhur me regjistrimin e aplikacionit. Ky është një sinjal i kuptueshëm besimi, por e lidh gjithashtu përdorshmërinë e autorizimit të hapur me procedurat e biznesit dhe partneritetit të Microsoft.

Google dhe Gmail: shqyrtimi i lejeve mund të bëhet pengesë për produktin

Procesi i Gmail kontrollohet më shumë në mënyrë qendrore. Klasifikimet e politikave të përshkruara në kohën e publikimit e identifikojnë gmail.send si të ndjeshme dhe gmail.readonly si të kufizuar. Aplikacionet publike që kërkojnë këto leje mund të kenë nevojë për prova të markës dhe domenit, një arsyetim të saktë për fushën e lejeve dhe një video demonstruese, sipas përdorimit.

Videoja duhet të tregojë gjithë rrjedhën OAuth, ekranin e saktë të pëlqimit dhe funksionet që përdorin çdo fushë të kërkuar lejesh. Nëse arsyetimi refuzohet ose, sipas vlerësimit të shqyrtuesit, paraqitja nuk përputhet me aplikacionin, mund të pasojnë pyetje shtesë, regjistrime të reja ose një dorëzim tjetër.

Artikulli i publikuar citon vlerësime jo detyruese të Google prej dy deri në tri ditë pune për verifikimin e markës, dhjetë ditë pune për lejet e ndjeshme dhe deri në gjashtë javë për lejet e kufizuara. Ruajtja ose transmetimi i të dhënave të kufizuara Gmail në një server mund të kërkojë gjithashtu një vlerësim sigurie të përsëritur çdo vit. Këto janë përshkrimet e politikave dhe vlerësimet e lidhura me publikimin origjinal, jo një premtim i ri për kohën e miratimit.

Kufiri prej 100 përdoruesish ka pasoja praktike

Në modalitetin e testimit, qasja kufizohet te më së shumti 100 përdorues testimi të listuar shprehimisht, autorizimet e të cilëve skadojnë pas shtatë ditësh sipas kushteve të përshkruara në udhëzimin e lidhur të Google. Aplikacionet e paverifikuara mund të përballen edhe me një kufi total prej 100 përdoruesish të rinj gjatë gjithë jetës së tyre.

Nëse një fushë lejesh e ndjeshme ose e kufizuar refuzohet, përdoruesit nuk mund të përdorin më atë fushë të pamiratuar. Një kufi ose refuzim nuk është pra thjesht një paralajmërim administrativ: ai mund të ndalojë funksionin e produktit që përdoruesi po përpiqet të aktivizojë.

Pse Hassolux ka nevojë për këto leje

Hassolux është një platformë pune për bizneset e ndërtimit dhe shërbimeve, që bashkon projektet, dokumentet, faturat dhe komunikimin në një rrjedhë pune të gjurmueshme. Një përdorues i autorizuar e aktivizon me qëllim lidhjen opsionale të kutisë postare.

Për Microsoft 365, qasja e deleguar Mail.Read dhe Mail.Send mbështet leximin e mesazheve hyrëse në emër të përdoruesit të identifikuar dhe dërgimin e emaileve me dokumente të kërkuara shprehimisht prej tij. Për Gmail, gmail.readonly merr mesazhe të zgjedhura dhe bashkëngjitje PDF/XML, ndërsa gmail.send përdoret veçmas për email dalës të nisur nga përdoruesi.

Hassolux kërkon vetëm në periudhën e zgjedhur nga përdoruesi, lexon dërguesin, subjektin dhe kohën e marrjes dhe importon bashkëngjitje të mbështetura PDF ose XML për përpunimin e faturave. Nuk lëviz, shënon, ndryshon ose fshin mesazhe Gmail. Dërgimi është i veçantë dhe ndodh vetëm pas një veprimi specifik të përdoruesit. Lidhja mund të hiqet dhe gjithashtu të revokohet te ofruesi.

Kërkesa për një fushë më të ngushtë lejesh mund të bëhet teknikisht kundërthënëse këtu. Një leje vetëm për metadata nuk ofron përmbajtjen e mesazhit ose bashkëngjitjet e faturave; aplikacioni nuk mund të importojë një dokument që nuk lejohet ta lexojë. Për këtë funksion të dukshëm, gmail.readonly kërkohet si leja më e ngushtë e Google që ofron qasjen e nevojshme, jo si grumbullim paraprak të drejtash më të gjera.

Përvoja jonë: demonstrime të përsëritura dhe sërish refuzim

Për Hassolux, verifikimi i Google përfshiu më shumë sesa zbatimin e integrimit. Prodhuam vazhdimisht video demonstruese, pritëm ciklet e shqyrtimit, iu përgjigjëm emaileve të statusit dhe shpjeguam pse leja ishte e nevojshme. Refuzimi i asaj lejeje heq më shumë sesa një leje abstrakte API: heq funksionin për të cilin përdoruesi dëshiron të lidhë kutinë e vet postare.

Të dhënat e ndjeshme të emailit justifikojnë kërkesa të forta sigurie. Megjithatë, një shqyrtim duhet të dallojë mbledhjen e tepërt nga një leje minimale teknikisht e nevojshme. Përndryshe parimi i privilegjit minimal bëhet i pamundur për t'u përmbushur: platforma nuk ofron leje më të ngushtë të përdorshme, por e refuzon lejen e disponueshme si tepër të gjerë. Ky është rrëfimi dhe argumenti i autorit për përvojën e shqyrtimit, jo pretendim se të gjitha aplikacionet trajtohen njësoj.

Çfarë duhet të ofrojë një proces i drejtë verifikimi

Përmirësimet e propozuara synojnë të ruajnë mbrojtjen, ndërsa i bëjnë të realizueshme integrimet e pavarura.

• Kritere të qarta që mund të kontrollohen paraprakisht: zhvilluesit duhet ta dinë cilat përdorime lejohen para zbatimit.
• Vendime specifike dhe të kuptueshme: një refuzim duhet të identifikojë mospërputhjen konkrete teknike ose të lidhur me privatësinë.
• Prova proporcionale: vlerësoni rrjedhën e të dhënave, vendndodhjen e ruajtjes dhe rrezikun real, jo kryesisht madhësinë e publikuesit.
• Shqyrtime të ripërdorshme: një ndryshim i vogël produkti nuk duhet ta rinisë gjithë procesin e provave.
• Një ankim teknik kuptimplotë: merrni parasysh rastet kur ofruesi nuk ofron një fushë më të ngushtë lejesh që funksionon.
• Zgjedhje efektive për përdoruesin: pëlqimi i informuar dhe revokimi në çdo kohë duhet të peshojnë më shumë sesa kufizimet e përgjithshme të platformës.

Autorizimi i hapur duhet të mbetet i hapur

Ne mbështesim OAuth, autentikim më të fortë dhe mbrojtje të qëndrueshme të të dhënave të përdoruesve. Pikërisht për këtë duhet të jetë e mundur kritika ndaj mekanizmave të miratimit të ndërtuar mbi të. Siguria duhet t'i mbrojë njerëzit nga aplikacionet e dëmshme pa rritur pa kujdes pengesat e hyrjes ose pa forcuar kontrollin e pronarëve të platformave mbi softuerin e ndërveprueshëm.

Një standard mund të jetë i hapur në letër. Në praktikë, hapja kërkon gjithashtu që zhvilluesit e pavarur, sipërmarrjet e reja dhe bizneset e vogla të softuerit të mund ta përdorin nën kushte transparente dhe të drejta. E ardhmja e internetit nuk duhet të varet nga leja e një grushti platformash për çdo integrim teknikisht të nevojshëm.