Atkuriamas autentiškumas

Ką reiškia „RESTful“ autentiškumas ir kaip jis veikia? „Google“ negaliu rasti geros peržiūros. Mano vienintelis supratimas yra tai, kad URL persiunčiate sesijos raktą (pakartotinį), tačiau tai gali būti labai neteisinga.

671
26 нояб. įkūrė Jim Keener 26 nov. 2008-11-26 04:47 '08 at 4:47 2008-11-26 04:47
@ 13 atsakymų

Kaip elgtis su autentifikavimu „RESTful Client-Server“ architektūroje, tai yra diskusija.

Paprastai ją galima pasiekti SOA pasaulyje per HTTP per:

  • HTTP pagrindinė auth per HTTPS;
  • Slapukai ir sesijos valdymas;
  • Ženklas HTTP antraštėse (pvz., OAuth 2.0);
  • Prašyti autentifikavimo su papildomomis parašo parinktimis.

Šiuos metodus reikės pritaikyti ar net geriau, kad geriausiai atitiktų jūsų programinės įrangos architektūrą.

Kiekviena autentifikavimo schema turi savo PRO ir CON, priklausomai nuo jūsų saugumo politikos ir programinės įrangos architektūros tikslo.

HTTP pagrindinio auth perjungimas per HTTPS

Tai pirmasis sprendimas, pagrįstas standartiniu HTTPS protokolu, kurį naudoja dauguma interneto paslaugų.

 GET /spec.html HTTP/1.1 Host: www.example.org Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== 

Lengva įdiegti, pagal numatytuosius nustatymus visose naršyklėse, tačiau turi keletą gerai žinomų Atgalinės nuorodos, pvz., Baisaus autentifikavimo >

Galime naudoti „ Authentication Digest“ , tačiau tai taip pat reikalauja HTTPS, nes jis yra pažeidžiamas „ MiM“ arba „ Replay“ ir yra specifinis HTTP.

Sesija per slapukus

Tiesą sakant, serveryje valdoma sesija iš esmės nėra bevertė.

Viena iš galimybių būtų išsaugoti visus duomenis į slapuko turinį. Ir, savo nuožiūra, slapukas apdorojamas serverio pusėje (klientas netgi nesistengia interpretuoti slapukų duomenų: jis tiesiog siunčia jį atgal į serverį kiekvienam tolesniam prašymui). Tačiau šie slapukų duomenys rodo taikomųjų programų duomenis, todėl klientas turi tvarkyti jį, o ne serverį, švariame be pilietybės pasaulyje.

 GET /spec.html HTTP/1.1 Host: www.example.org Cookie: theme=light; sessionToken=abc123 

Pati slapukų technika yra susijusi su HTTP, todėl ji nėra iš tikrųjų atsipalaidavusi, kuri turėtų būti nepriklausoma nuo protokolo, IMHO. Jis yra pažeidžiamas MiM arba Replay atakoms.

Teikiama per simbolį (OAuth2)

Alternatyva yra įdėti tokeną į HTTP antraštes, kad prašymas būtų patvirtintas. Tai yra, pavyzdžiui, OAuth 2.0. Žr. RFC 6749 :

  GET /resource/1 HTTP/1.1 Host: example.com Authorization: Bearer mF_9.B5f-4.1JqM 

Trumpai tariant, tai labai panaši į slapukų rinkmeną ir patiria tas pačias problemas: jis neturi asmens be pilietybės, remdamasis HTTP perdavimo duomenimis, todėl daugelis saugumo trūkumų, įskaitant „MiM“ ir „Replay“, turėtų būti naudojami tik per HTTPS.

Prašyti autentifikavimo

Prašymo autentifikavimas apima kiekvieno RESTful užklausos pasirašymą per kelis papildomus URI parametrus. Žr. Šį pagalbos straipsnį .

Jis buvo apibrėžtas šiame straipsnyje:

Visi REST užklausos turi būti patvirtintos pasirašant užklausos parametrus, surūšiuotus mažosiomis raidėmis, abėcėlės tvarka, naudojant privačius įgaliojimus kaip parašo ženklą. Pasirašymas turi vykti prieš koduojant URL užklausos eilutę.

Šis metodas gali būti labiau suderinamas su architektūra ir taip pat gali būti įgyvendintas naudojant paprastą sesijos valdymą (naudojant atminties seansus vietoj duomenų bazės išsaugojimo).

Pavyzdžiui, čia yra bendras URI pavyzdys iš aukščiau pateiktos nuorodos:

 GET /object?apiKey=Qwerty2010 

turėtų būti perduodami:

 GET /object?timestamp=1261496500> 

Pasirašyta linija yra /object?apikey=Qwerty2010> , o parašas yra šios eilutės SHA256 /object?apikey=Qwerty2010> naudojant privatų API raktų komponentą.

Serverio duomenų talpyklos gali būti visada prieinamos. Pvz., Mūsų sistemoje atsakymus saugome SQL lygiu, o ne URI lygiu. Todėl šio pasirinktinio parametro pridėjimas nepažeidžia talpyklos mechanizmo.

Daugiau informacijos apie RESTful autentiškumą mūsų ORM / SOA / MVC kliento-serverio infrastruktūroje, pagrįstą JSON ir REST, rasite šiame straipsnyje . Kadangi mes leidžiame bendrauti ne tik per HTTP / 1.1, bet ir per minėtus vamzdžius arba GDI pranešimus (vietoje), bandėme įdiegti tikrą tikrovišką bandomąjį modelį, o ne pasikliauti HTTP ypatumais (pvz., Antraštėmis ar slapukais).

Praktiškai tikėtinas „OAuth 2.0“ „MAC Tokens“ autentifikavimas gali būti didžiulis dabartinės „Token Submission“ schemos pagerinimas. Bet tai vis dar vyksta ir yra susijęs su HTTP perdavimu.

Išvada

Turi būti padaryta išvada, kad REST yra pagrįstas ne tik HTTP, net jei praktikoje jis daugiausia įgyvendinamas per HTTP. REST gali naudoti kitus komunikacijos lygius. Taigi, atkuriamas autentifikavimas yra ne tik HTTP autentifikavimo sinonimas, neatsižvelgiant į tai, ką „Google“ atsako. Jis neturėtų naudoti HTTP mechanizmo, bet turėtų būti ištrauktas iš komunikacijos sluoksnio.

527
23 авг. Arnaud Bouchez atsakymas 23 rug . 2011-08-23 12:29 '11, 12:29, 2011-08-23 12:29

Aš abejoju, kad žmonės entuziastingai šaukė „HTTP autentifikavimo“, kada nors bandė sukurti naršyklę (vietoj žiniatinklio paslaugos iš mašinos į mašiną) naudojant „REST“ (be nusikaltimo - aš nemanau, kad jie kada nors susidūrė su komplikacijomis)

Problemos, kurias atradau naudojant HTTP autentifikavimą „RESTful“ paslaugose, kurios sukuria HTML puslapius peržiūrai naršyklėje, yra šios:

  • Vartotojas paprastai gauna negraži naršyklės prisijungimo >
  • Atsijunkite arba užsiregistruokite kitu vardu - problema - naršyklės atsiųs autentifikavimo informaciją į svetainę, kol uždarysite >
  • laikas yra sudėtingas

Labai įžvalgus straipsnis, kuris išsprendžia šiuos klausimus pagal tašką, tačiau tai veda prie didelės naršyklės „JavaScript“ įsilaužėlių, problemų sprendimo būdų, problemų sprendimo būdų ir tt Taigi, jis taip pat nėra suderinamas su pažangiuoju metodu, todėl, kai išleidžiamos naujos naršyklės, būtina nuolatinė priežiūra. Nemanau, kad tai yra švarus ir aiškus dizainas, taip pat jaučiu, kad turiu daug papildomo darbo ir galvos skausmo, kad galėčiau entuziastingai parodyti savo REST piktogramą savo draugams.

Manau, kad slapukas yra sprendimas. Bet palaukite, slapukai yra pikti, ar ne? Ne, jie nėra tokie, kaip dažnai naudojami slapukai, tai blogis. Pati slapukas yra tik kliento informacija, kaip ir HTTP autentifikavimo informacija, kurią naršyklė stebės naršydama. Ir ši kliento informacijos dalis siunčiama į serverį kiekvienam prašymui, pavyzdžiui, HTTP autentifikavimui. Akivaizdu, kad vienintelis skirtumas yra tas, kad šios kliento būklės dalies turinį serveris gali nustatyti kaip atsako dalį.

RESTful išteklių sesijų kūrimas naudojant tik šias taisykles:

  • Sesijoje rodomas raktas į vartotojo ID (ir galbūt paskutinio veiksmo, skirto pertraukoms, laiko žymė)
  • Jei sesija egzistuoja, tai reiškia, kad raktas galioja.
  • Prisijungimas reiškia POSTing į / sesijas, naujasis raktas yra nustatytas kaip slapukas
  • Išsiregistravimas reiškia DELETEING / sessions / {key} (su perkrautu POST, nepamirškite, kad mes esame naršyklė, o HTML 5 vis dar toli)
  • Atpažinimas atliekamas siunčiant raktą kaip slapuką kiekvienam prašymui ir tikrinant sesijos buvimą ir galiojimą

Vienintelis skirtumas tarp HTTP autentifikavimo yra tas, kad autentifikavimo raktas generuojamas serveryje ir siunčiamas klientui, kuris ir toliau siunčia jį, o ne klientas, apskaičiuojantis jį iš įvestų įgaliojimų.

convert42 priduria, kad naudojant https (ko mums reikia), svarbu, kad slapukas nustatytų saugią vėliavą, kad autentiškumo informacija niekada nebūtų siunčiama per nesaugų ryšį. Puikus momentas, jis nematė.

Manau, kad tai yra pakankamas sprendimas, kuris puikiai veikia, bet turiu pripažinti, kad neturiu pakankamai saugumo ekspertų, kad galėčiau nustatyti galimus šios schemos įvykius - tik žinau, kad šimtai netinkamų interneto programų , naudokite iš esmės tą patį prisijungimo protokolą ($ _SESSION inphp, HttpSession Java EE ir tt). Slapuko antraštės turinys paprasčiausiai naudojamas ištekliams adresuoti serverio pusėje, kaip ir gaunančioji kalba gali būti naudojama vertimo ištekliams pasiekti. Manau, kad tai yra tas pats, bet galbūt kiti ne? Ką jūs manote?

405
16 июля '09 в 10:39 2009-07-16 10:39 atsakymą pateikė skrebbel liepos 16 d. , 09:39, 2009-07-16 10:39

Šiuo klausimu apie tai gerai pasakė geri žmonės. Bet čia yra mano 2 centai.

Yra 2 sąveikos režimai:

  • asmuo į automobilį (htm)
  • mašina (MTM)

Įrenginys yra bendras vardiklis, išreikštas kaip REST API, ir subjektai / klientai yra žmonės arba mašinos.

Dabar, tikrosios RESTful architektūros, be pilietybės sąvoka reiškia, kad visos atitinkamos taikomųjų programų būsenos (t.y. kliento pusės) turi būti pateiktos kartu su kiekvienu prašymu. Atitinkama priemonė reiškia, kad užklausai apdoroti ir atitinkamam atsakymui pateikti reikia REST API.

Kai tai laikoma „asmeninio į kompiuterį“, „naršyklės“ taikomosiomis programomis, kaip nurodyta „Scrabel“, tai reiškia, kad naršyklėje veikianti (žiniatinklio programa) turės nusiųsti savo būseną ir atitinkamą informaciją naudodama kiekvieną prašymas, kurį jis pateikia „REST API“ ant nugaros.

Apsvarstykite tai: turite duomenų / informacijos platformą, atstovaujamą REST API rinkiniu. Galite turėti savitarnos BI platformą, kuri apdoroja visus duomenų kubus. Bet norite, kad jūsų (žmogaus) klientai galėtų tai pasiekti per (1) žiniatinklio programą, (2) mobiliąją programą ir (3) kai kurios trečiosios šalies programą. Galų gale net MTM grandinė veda į HTM - dešinėje. Taigi, žmonių naudotojai lieka informacijos grandinės viršuje.

Per pirmuosius du atvejus, jei turite sąveiką tarp mašinų, informaciją faktiškai vartoja žmogus. Pastaruoju atveju turite mašinų programą, kuri naudoja REST API.

Autentiškumo sąvoka taikoma visomis kryptimis. Kaip tai vystote, kad jūsų REST API būtų prieinamos vienoje saugioje formoje? Kaip matau, yra du būdai:

Way-1:

  • Pradžioje nėra prisijungimo. Kiekvienas prašymas prisijungia.
  • Klientas siunčia savo identifikavimo parametrus + konkrečius užklausos parametrus kiekvienam prašymui
  • „REST API“ juos priima, apsisuka, saugo vartotoją (nepriklausomai nuo to, kas yra) ir patvirtina auth
  • Jei nustatytas auth, tarnauja užklausai; kitaip neigia atitinkamą HTTP būsenos kodą
  • Pakartokite aukščiau pateiktą informaciją kiekvienam jūsų REST API REST API.

Way-2:

  • Klientas pradeda nuo auth užklausos
  • Prisijungimo REST API tvarkys visus tokius prašymus.
  • Jis priima automatinius parametrus (API raktas, uid / pwd arba ką tik pasirinkote) ir patikrina auth naudojimą vartotojo saugykloje (LDAP, AD arba MySQL DB ir tt).
  • Jei patvirtinama, sukuriamas autentifikavimo raktas ir klientas / abonentas jį grąžina.
  • Tada skambinantysis atsiunčia šį autentifikavimo raktą + prašo tam tikrų parametrų, naudodamas kiekvieną kitą užklausą kitiems verslo REST API, prieš išeinant arba kol baigiasi nuomos terminas.

Akivaizdu, kad „Way-2 API REST“ reikės būdų atpažinti ir pasitikėti tokiu ženklu kaip galiojančiu. API API patvirtino autentifikavimą ir todėl, kad raktas būtų patikimas kitiems REST API jūsų kataloge.

Tai, žinoma, reiškia, kad autentifikavimo raktas / raktas turėtų būti saugomas ir platinamas tarp REST API. Ši bendra, patikima raktinių žodžių saugykla gali būti vietinė / susieta, o tai leidžia kitoms organizacijoms REST API pasitikėti tarpusavyje.

Bet aš atsisakau.

Faktas yra tai, kad „būsena“ (kliento autentifikavimo būsena) turi būti palaikoma ir bendrinama, kad visi REST API galėtų sukurti pasitikėjimo ratą. Jei to nepadarysime, tai yra kelias-1, turime pripažinti, kad autentiškumo patvirtinimo veiksmas turi būti atliktas bet kuriam / visiems gaunamiems prašymams.

Autentiškumo tikrinimas yra intensyvus procesas. Įsivaizduokite, kad jūs vykdote SQL užklausas kiekvienam įeinančiam užklausai savo vartotojo saugykloje, kad patikrintumėte, ar laikomasi „uid / pwd“ reikalavimų. Arba galite užšifruoti ir atlikti maišymo atitikmenis (AWS stilius). Ir architektūroje kiekviena REST API turės tai padaryti, manau, naudojant bendrą prisijungimo paslaugą. Nes jei jūs to nepadarysite, jūs visur sunaikinsite auth kodą. Didelis netvarka.

Taigi daugiau sluoksnių, daugiau vėlavimo.

Dabar pasiimkite Way-1 ir kreipkitės į HTM. Ar jūsų vartotojas (asmuo) tikrai rūpinasi, jei jums reikia siųsti uid / pwd / hash arba ką nors su kiekvienu prašymu? Ne, jei nepažeisite jos, palikdami auth / login puslapį kas antrą kartą. Sėkmės, jei turite klientų. Taigi, tai, ką darysite, išsaugokite prisijungimo informaciją kažkur kliento pusėje, naršyklėje, pačioje pradžioje ir atsiųskite ją su kiekvienu pateiktu prašymu. Naudotojui (vartotojui) ji jau prisijungė ir „sesija“ yra prieinama. Bet iš tikrųjų kiekvienas prašymas yra patvirtintas.

Tas pats su „Way-2“. Jūsų (vartotojo) vartotojas niekada nepastebės. Todėl nebuvo jokios žalos.

Ką daryti, jei taikysime „Way-1“ į MTM? Šiuo atveju, nuo jo mašinos, mes galime atsikratyti šio vaikino, prašydami jo pateikti autentiškumo informaciją su kiekvienu prašymu. Niekas rūpinasi! „Way-2“ važiavimas MTM nesukels jokios konkrečios reakcijos; jo velniškas automobilis. Tai gali rūpintis mažiau!

Taigi klausimas yra tas, kas jums tinka. Nevalstybiškumas turi mokėti kainą. Mokėkite kainą ir pereikite. Jei norite būti puristas, tai už tai mokėkite ir toliau.

Galų gale filosofija nesvarbu. Svarbiausia yra informacijos paieškos, pateikimo ir vartojimo patirtis. Jei žmonės mėgsta jūsų API, atlikote savo darbą.

129
24 нояб. Atsakymą pateikė Kingz lapkričio 24 d. 2013-11-24 01:19 '13, 1:19, 2013-11-24 01:19

Štai tikrai ir visiškai atnaujinamas autentifikavimo sprendimas:

  • Sukurkite viešojo / privataus rakto porą autentifikavimo serveryje.
  • Platinkite viešąjį raktą visuose serveriuose.
  • Kai klientas yra patvirtintas:

    3.1. išduoti ženklą, kuriame yra:

    • Galiojimas
    • naudotojo vardas (neprivaloma)
    • IP vartotojai (neprivaloma)
    • slaptažodžio maišymas (neprivaloma)

    3.2. Šifruoti tokeną su privačiu raktu.

    3.3. Siųsti naudotojui šifruotą raktą.

  • Kai naudotojas pasiekia bet kurią API, jis taip pat turi perduoti savo autentifikavimo raktą.

  • Serveriai gali patikrinti, ar raktas galioja, iššifruojant jį su auth serverio viešuoju raktu.

Tai yra be pilietybės / atkuriamas autentifikavimas.

Atminkite, kad jei įjungtas slaptažodžio maišymo kodas, naudotojas taip pat išsiuntė nešifruotą slaptažodį kartu su autentifikavimo ženklu. Serveris gali patikrinti, ar slaptažodis sutampa su slaptažodžiu, kuris buvo naudojamas autentifikavimo raktui sukurti, lyginant hashes. Tam reikės saugaus ryšio naudojant HTTPS. Kliento pusėje esantis „Javascript“ gali apdoroti vartotojo slaptažodį ir laikyti jį kliento pusėje atmintyje arba slapuke, galbūt užšifruotame naudojant viešąjį serverį.

47
15 окт. atsakymas, kurį pateikė jcoffland Oct 15 2013-10-15 00:29 '13 0:29 2013-10-15 00:29

Sąžiningai, aš čia matiau puikius atsakymus, bet kažkas, kas man kelia nerimą, yra tai, kad kažkas visiškai sutiks su pilietybės neturėjimu, kur jis taps dogmatiniu. Jis man primena tuos senus „Smalltalk“ gerbėjus, kurie tik norėjo priimti gryną OO, ir jei kažkas nėra objektas, tai darote tai neteisingai. Duokite man pertraukos.

Daroma prielaida, kad RESTful požiūris palengvins jūsų gyvenimą ir sumažins sesijų išlaidas ir išlaidas, pabandys tai sekti, nes tai išmintingas dalykas, bet tuo metu, kai sekate drausmę (bet kurią discipliną / vadovą), kur jis nebesuteikia tokio pranašumo. kuriam jis buvo skirtas, tada tai darote neteisingai. Kai kurios geriausios kalbos šiandien turi tiek funkcinį programavimą, tiek objekto orientaciją.

Jei paprasčiausias būdas išspręsti problemą yra išsaugoti autentifikavimo raktą į slapuką ir išsiųsti jį per HTTP antraštę, tada atlikite tai, tiesiog nepiktnaudžiaukite. Atminkite, kad sesijos yra blogos, kai jos tampa sunkios ir didelės, jei visa sesija susideda iš trumpos eilutės, kurioje yra raktas, tada kas yra didelis dalykas?

Aš esu atviras komentarų pataisymams, bet aš nematau taško (iki šiol), kad mūsų gyvenimas būtų apgailėtinas, o ne laikyti didelį maišų žodyną mūsų serveryje.

34
13 авг. atsakymas pateikiamas arg20 13 rug . 2013-08-13 23:09 '13, 23:09, 2013-08-13 23:09

Visų pirma, „RESTful“ žiniatinklio paslauga yra SAFE (arba, kitaip tariant, „SESSIONLESS“). Taigi „RESTful“ paslauga neturi ir neturėtų turėti sesijos ar slapukų sąvokos. Autentiškumo patvirtinimo ar autorizacijos būdas RESTful paslaugoje yra HTTP autorizacijos antraštės, kaip apibrėžta RFC 2616 HTTP specifikacijoje, naudojimas. Kiekviename atskirame prašyme turi būti HTTP autorizacijos antraštė, o užklausa turi būti siunčiama per HTTP ryšį (SSL). Tai tinkamas būdas atlikti autentifikavimą ir patvirtinti užklausų patvirtinimą „RESTful HTTP“ žiniatinklio paslaugose. Įdiegiau „Cisco PRIME Performance Manager“ programą „Cisco Systems“. И как часть этой веб-службы, я также внедрил аутентификацию/авторизацию.