Kodėl OAuth v2 yra prieigos ir atnaujinimo žetonų?

„OAuth 2.0“ protokolo projekto 4.2 skirsnyje teigiama, kad autorizacijos serveris gali grąžinti „ access_token (kuris naudojamas autentifikavimui su ištekliumi) ir refresh_token , kuris naudojamas tik kuriant naują access_token :

https://tools.ietf.org/html/rfc6749#section-4.2

Kodėl yra abu? Kodėl ne tik padaryti access_token paskutinį kartą, kol bus refresh_token ir refresh_token ?

520
15 авг. nustatė dave mankoff 15 rug . 2010-08-15 18:25 '10, 06:25 PM 2010-08-15 18:25
@ 14 atsakymų

Atnaujinimo žetonų idėja yra ta, kad jei prieigos raktas yra pažeistas, nes jis yra trumpalaikis, užpuolikas turi ribotą >

Atnaujinimo žetonai, jei jie yra pažeisti, yra nenaudingi, nes užpuolikas reikalauja prie kliento ID ir paslapties, be atnaujinimo žetono, kad gautų prieigos raktą.

Atsižvelgiant į tai , kadangi kiekvienas skambinimas tiek autorizacijos serveriui, tiek išteklių serveriui atliekamas per SSL, įskaitant pirminį kliento identifikatorių ir paslaptį, kai jie prašo prieigos / atnaujinimo žetonų - nesu įsitikinęs, kaip prieigos raktas yra „labiau pažeistas“ nei ilgalaikis atnaujinimo raktas ir klientas slaptas derinys.

Tai, žinoma, skiriasi nuo įgyvendinimų, kuriuose nekontroliuojate autorizacijos ir išteklių serverių.

Čia yra gera gija apie atnaujinimo žetonų naudojimą: OAuth archyvus .

Citata iš aukščiau paminėtų dalykų, kalbant apie raktinio žodžio atnaujinimo saugumo tikslus:

Atnaujinimo žetonai ... sumažina ilgalaikio „access_token“ nuotėkio riziką (užklausos parametras žurnalo faile neapsaugotame išteklių serveryje, beta versijoje arba prastai užkoduotame išteklių serveryje, JS SDK kliente ne https svetainėje, kurioje prieigos_prieš slapuką ir kt.) .)

383
26 авг. atsakymas pateikiamas „ catchdave“ 26 d. 2011-08-26 21:52 '11, 21:52, 2011-08-26 21:52

Nuoroda į „Catchdave“ pateiktą diskusiją turi kitą teisingą požiūrį (originalą, mirusį ryšį) , kurį padarė Dick Hardt, ir, manau, čia verta paminėti, be to, kas buvo parašyta aukščiau:

Mano prisiminimai apie atnaujintą lustą buvo saugumas ir atšaukimas. <...>

atšaukimas: jei prieigos raktas yra savarankiškas, leidimas gali būti atšauktas neišduodant naujų prieigos žetonų. Ištekliai nereikalauja užklausos autorizacijos serveriui, kad sužinotų, ar prieigos raktas galioja. Tai supaprastina prieigos raktų patvirtinimą ir supaprastina mastelio nustatymą ir paramą keliems autorizavimo serveriams. Kai prieigos raktas galioja, yra laiko >

Iš tiesų, tais atvejais, kai išteklių serveris ir autorizacijos serveris yra tas pats objektas, o kai ryšys tarp vartotojo ir bet kurio iš jų yra (kaip paprastai) vienodai saugus, yra mažai prasmės laikyti atnaujinimo raktą atskirai nuo prieigos rakto.

Nors, kaip minėta citate, kitas atnaujinimo žetonų vaidmuo yra užtikrinti, kad naudotojas galėtų bet kuriuo metu atšaukti prieigos raktą (pvz., Naudodamas savo sąsajoje esančią žiniatinklio sąsają), tuo pačiu metu išlaikant sistemos mastelį. .

Paprastai žetonai gali būti atsitiktiniai identifikatoriai, nukreipiantys į konkretų įrašą Serverio duomenų bazėje, arba jie gali turėti visą informaciją (žinoma, ši informacija turi būti pasirašyta, pavyzdžiui, naudojant MAC ).

Kaip sistema turėtų dirbti su ilgaamžiais prieigos ženklais

Serveris leidžia Klientui prieiti prie naudotojo duomenų iš anksto nustatytame sričių rinkinyje, išduodamas ženklą. Kadangi norime, kad ženklas būtų atšauktas, privalome išsaugoti raktą į duomenų bazę kartu su atšaukimo vėliava arba išvalyti (kitaip, kaip tai padarytumėte autonominiu ženklu?) Duomenų bazėje gali būti tiek pat, kiek „ len(users) x len(registered clients) x len(scopes combination) įrašai. Tada kiekviena API užklausa turėtų patekti į duomenų bazę. Nors prašymai dėl tokios duomenų bazės, atliekantys O (1), yra gana trivialūs, pats gedimo taškas gali neigiamai paveikti sistemos mastelį ir našumą.

Kaip sistema turėtų dirbti su ilgaamžiu atnaujinimo raktu ir trumpalaikiu prieigos raktu

border=0

Čia išduodami du raktai: atsitiktinio atnaujinimo raktas su atitinkamu įrašu duomenų bazėje ir pasirašytas neprisijungęs prieigos raktas, kuriame, be kita ko, yra galiojimo laiko žymos laukas.

Kadangi prieigos raktas yra savarankiškas, mums nereikia prieiti prie duomenų bazės, kad patvirtintume jo galiojimą. Viskas, ką turime padaryti, yra dekoduoti tokeną ir patvirtinti parašą bei laiko žymę.

Tačiau mums vis tiek reikia saugoti atnaujinimo žetonų duomenų bazę, tačiau užklausų į šią duomenų bazę skaičių paprastai lemia prieigos rakto galiojimo laikas (kuo ilgesnis tarnavimo laikas, tuo mažesnis prieigos greitis).

Norint atšaukti Kliento prieigą iš konkretaus naudotojo, turime pažymėti atitinkamą atnaujinimo raktą kaip „atšauktą“ (arba visiškai jį pašalinti) ir nustoti išduoti naujus prieigos raktus. Akivaizdu, kad yra >

kompromisus

Atnaujinimo žetonai iš dalies pašalina „SPoF“ (vieno taško nesėkmės) duomenų bazės prieigos raktus, tačiau jie turi tam tikrų akivaizdžių trūkumų.

  1. >

  2. Kliento logikos komplikacija.

    neatnaujinus žetonų

    • siųsti API užklausą su prieigos raktu
    • jei prieigos raktas negalioja, nebuvo įmanoma paprašyti naudotojo pakartotinio autentifikavimo

    su atnaujinimo žyma

    • siųsti API užklausą su prieigos raktu
    • Jei prieigos raktas negalioja, pabandykite jį atnaujinti naudodami atnaujinimo raktą.
    • jei atnaujinimo užklausa praėjo, atnaujinkite prieigos raktą ir iš naujo išsiųskite pradinę API užklausą
    • Jei atnaujinimo užklausa nėra baigta, paprašykite naudotojo pakartotinio autentifikavimo

Tikiuosi, kad šis atsakymas bus prasmingas ir padeda kažkam priimti išsamesnį sprendimą. Taip pat noriu pažymėti, kad kai kurie gerai žinomi „OAuth2“ paslaugų teikėjai, įskaitant „github“ ir „foursquare“, naudoja protokolą be atnaujinimo žetonų ir, atrodo, tai patenkinti.

475
14 окт. Romos Imankulovo atsakymą pateikė spalio 14 d. 2012-10-14 22:38 '12 10:38 val. 2012-10-14 22:38

Nepaisant visų nuostabių pirmiau pateiktų atsakymų, aš, kaip saugumo magistras ir programuotojas, anksčiau dirbęs eBay, kai mokiausi klientų apsaugos ir sukčiavimo, galiu pasakyti, kad atskiras prieigos raktas ir atnaujinimo raktas turi geresnę pusiausvyrą tarp naudotojo, kuris dažnai naudoja vartotojo vardą, priekabiavimo ./Pasirašykite slaptažodį ir išsaugokite įgaliojimus, kad būtų panaikinta prieiga prie galimo piktnaudžiavimo jūsų paslauga.

Pagalvokite apie tokius scenarijus. Jūs suteikiate prieigos raktą naudotojui 3600 sekundžių ir atnaujinate žymenį daug ilgiau nei vieną dieną.

  1. Vartotojas yra geras vartotojas, jis yra namuose ir įjungia / išjungia jūsų svetainę, perka ir ieško savo „iPhone“. Jo IP adresas nepasikeičia ir jūsų serverio apkrova yra labai maža. Kaip ir 3-5 puslapių užklausos kas minutę. Kai 3600 sekundžių paspaudus prieigos raktą baigėsi, jam reikia naujo su atnaujinimo žyma. Mes esame serverio pusėje, tikrinant jo veiklos istoriją ir IP adresą, manome, kad jis yra žmogus ir elgiasi pats. Mes suteikiame jam naują prieigos raktą, kad galėtume toliau naudotis mūsų paslaugomis. Naudotojui nereikės įvesti naudotojo vardo / slaptažodžio dar kartą, kol jis nepasiekia vienos atnaujinimo simbolio dienos.

  2. Vartotojas - neatsargus vartotojas. Jis gyvena Niujorke, JAV, uždarė savo virusų programą ir buvo įsilaužęs į hakerį Lenkijoje . Kai įsilaužėlis gavo prieigos raktą ir atnaujino tokeną, jis bando įsivaizduoti vartotoją ir naudoti mūsų paslaugą. Tačiau pasibaigus trumpalaikiam prieigos raktui, kai įsilaužėlis bando atnaujinti prieigos raktą, serveryje pastebėjome dramatišką IP adreso pasikeitimą naudotojo elgesio istorijoje (Ei, šis vaikinas prisijungia prie JAV ir dabar atnaujina prieigą Lenkijoje tik po 3600s ???). Mes sustabdome atnaujinimo procesą, panaikiname atnaujinimo raktą ir vėl siūlome įvesti naudotojo vardą / slaptažodį.

  3. Vartotojas yra kenkėjiškas vartotojas. Jis ketina piktnaudžiauti mūsų paslaugomis, skambindamas mūsų API 1000 kartų per minutę, naudodamas robotą. Jis galėjo tai padaryti iki 3600 sekundžių, kai jis bandė atnaujinti prieigos raktą, pastebėjome jo elgesį ir manėme, kad jis nėra žmogus. Atmetame ir sustabdome atnaujinimo procesą ir paprašome jį iš naujo įvesti naudotojo vardą / slaptažodį. Tai gali sugadinti automatinį roboto srautą. Bent jau jis yra nepatogu.

Matote, kad atnaujinimo raktas veikė gerai, kai stengiamės subalansuoti savo darbą, vartotojo patirtį ir galimą pavojų, kad žetonas bus pavogtas. Jūsų serverio pusėje esantis laikrodis gali patikrinti, ar API skambučių dažnumas yra didesnis nei IP, ir nustatyti, ar vartotojas yra geras vartotojas.

Kitas žodis: taip pat galite pabandyti apriboti žalos kontrolę nuo pavogtų žetonų / paslaugų piktnaudžiavimo naudojant pagrindinį IP stebėtoją arba kitas priemones kiekvienam API kvietimui. Bet tai yra brangi, nes turite skaityti ir rašyti vartotojo įrašus ir sulėtinti serverio atsaką.

132
18 июня '16 в 22:58 2016-06-18 22:58 Laalaguerio atsakymas birželio 18, 16 d., 10:58 pm 2016-06-18 22:58

Nė vienas iš šių atsakymų neatitinka pagrindinės priežasties atnaujinti žymas. Akivaizdu, kad visuomet galite gauti naują žetonų / atpažinimo ženklo porą, atsiųsdami savo kredencialus į auth serverį.

Taigi vienintelis atnaujinimo žetono tikslas yra apriboti kliento įgaliojimų, išsiųstų siunčiant į auth paslaugą, naudojimą. Kuo trumpesnis prieigos raktas ttl, tuo dažniau kliento įgaliojimai turės būti naudojami norint gauti naują prieigos raktą, taigi ir daugiau galimybių užpuolėjams užkirsti kelią kliento įgaliojimams (nors tai gali būti labai sunku bet kuriuo atveju, jei naudojate asimetrinį šifravimas). Todėl, jei turite vienkartinį atnaujinimo raktą, galite padaryti, kad ttl prieigos raktai būtų savavališkai maži, nekeliant pavojaus kliento įgaliojimams.

62
02 авг. atsakymas pateikiamas BT 02 rug. 2012-08-02 22:11 '12, 10:11 pm 2012-08-02 22:11

Norint pašalinti tam tikrą painiavą, reikia suprasti slapto rakto ir vartotojo slaptažodžio, kuris labai skiriasi.

Klientas yra programa / svetainė / programa / ..., kurią palaiko serveris, norintis autentifikuoti vartotoją naudojant trečiosios šalies autentifikavimo paslaugą. Kliento paslaptis yra (atsitiktinė) eilutė, žinoma tiek šiam klientui, tiek autentifikavimo serveriui. Naudodamas šią paslaptį, klientas gali identifikuoti save su autentifikavimo serveriu ir gauti leidimą kreiptis į prieigos raktus.

Norėdami gauti pirminį prieigos raktą ir atnaujinimo raktą, reikia:

  • Vartotojo ID
  • Vartotojo slaptažodis
  • Kliento ID
  • Kliento paslaptis

Norėdami gauti atnaujintą prieigos raktą, klientas naudoja šią informaciją:

  • Kliento ID
  • Kliento paslaptis
  • Atnaujinti srovę

Tai aiškiai rodo skirtumą: atnaujindamas klientas gauna leidimą atnaujinti prieigos raktus naudodamas savo kliento slaptą raktą ir tokiu būdu gali pakartotinai autentifikuoti vartotoją naudodamas atnaujinimo raktą, o ne vartotojo ID + slaptažodį. Tai neleidžia vartotojui iš naujo įvesti savo slaptažodžio.

Tai taip pat rodo, kad atnaujinimo žetono praradimas nėra problema, nes kliento ID ir paslaptis nežinoma. Tai taip pat rodo, kad būtina išlaikyti klientų paslaptį ir klientų privatumą.

34
04 марта '16 в 12:36 2016-03-04 12:36 atsakymą pateikė Adversus kovo 4 d. 16 d. 12:36 2016-03-04 12:36

Šis atsakymas pateiktas iš „Justin Reacher“ per standartinį OAuth 2 el. Pašto sąrašą, kuris siunčiamas su jo leidimu.


Atnaujinimo raktinio žodžio galiojimas priklauso nuo autorizacijos serverio (AS) - jie gali pasibaigti, atšaukti ir tt Skirtumas tarp atnaujinimo žyma ir prieigos raktas yra auditorija: atnaujinimo raktas grįžta tik į autorizacijos serverį, prieigos raktas patenka į išteklių serverį (RS).

Be to, tiesiog gauti prieigos raktą nereiškia, kad vartotojai yra prisijungę. Tiesą sakant, vartotojas gali būti netgi ne tas, kuris iš tikrųjų yra numatytas atnaujinimo žetonų naudojimas. Atnaujinant prieigos raktą, galėsite pasiekti API naudotojo vardą, nesakys, ar ten yra kokių nors naudotojų.

„OpenID Connect“ suteikia ne tik informaciją apie vartotoją iš prieigos raktinio žodžio, bet ir suteikia jums identifikatoriaus ženklą. Tai atskira duomenų dalis, skirta klientui, o ne AS arba RS. „OIDC“ turėtumėte tikėtis, kad kas nors iš tikrųjų yra „prisijungęs“ protokolu, jei galite gauti naują identifikatoriaus raktą. Atnaujinti tai vargu ar bus pakankamai.

Jei reikia daugiau informacijos, skaitykite http://oauth.net/articles/authentication/

32
31 авг. atsakymas duotas Manicode 31 r. 2015-08-31 02:04 '15, 02:04 2015-08-31 02:04

Klientai gali būti pažeisti daugeliu būdų. Pavyzdžiui, mobilusis telefonas gali būti klonuojamas. Ženklo galiojimo pabaigos buvimas reiškia, kad klientas turi autentifikuoti autorizacijos serverį. Atpažinimo metu autorizacijos serveris gali patikrinti kitas charakteristikas (IOW atlieka adaptyvų prieigos valdymą).

Atsarginės žetonai leidžia tik pakartotinai autentifikuoti klientą, kur, pakartotinai autorizuodamas, jis verčia dialogą su vartotoju, kurį daugelis nurodė nenorėdami daryti.

Atnaujinimo žetonai iš esmės yra toje pačioje vietoje, kur įprastos svetainės gali būti paprašytos periodiškai pakartotinai autentifikuoti vartotojus po valandos (pvz., Banko svetainė). Šiuo metu jis yra mažai naudojamas, nes dauguma socialinių svetainių nepatvirtina interneto vartotojų, todėl kodėl jie pakartotinai patvirtina klientą?

18
18 авг. Atsakymą pateikė Phil 18 rug. 2012-08-18 21:40 '12 21:40 2012-08-18 21:40

Siekiant dar labiau supaprastinti „BT“ atsakymą: naudokite atnaujinimo raktus, kai paprastai nereikia, kad vartotojas pakartotinai įvestų kredencialus, bet vis tiek nori, kad institucija panaikintų leidimus (atšaukdama atnaujinimo raktą)

Jūs negalite atšaukti prieigos rakto, tik atnaujinimo žetono.

11
27 апр. atsakymas pateikiamas bitcoder 27 apr. 2015-04-27 21:02 '15 - 21:02 2015-04-27 21:02

Kodėl ne tik padaryti „access_token“ paskutinį kartą, kol atnaujinama_token, ir jūs neturite refresh_token?

Be puikių atsakymų, kuriuos pateikė kiti žmonės, yra dar viena priežastis, kodėl jums reikia naudoti atnaujinimo žetonų ir jų veiksmus su skundais.

Kiekviename simbolyje yra teiginių, kurie gali apimti kažką naudotojo, jų vaidmenų ar programos sukūrusio tiekėjo vardu. Atnaujinus raktą, šie teiginiai atnaujinami.

Jei mes dažniau atnaujiname žymas, akivaizdu, kad mes tapsime labiau pabrėžti mūsų identifikavimo tarnybose, tačiau gauname tikslesnius ir naujausius pareiškimus.

8
19 янв. atsakymas duotas Heymega 19 jan. 2016-01-19 18:36 '16 at 18:36 pm 2016-01-19 18:36

Tarkime, jūs padarote access_token labai ilgą laiką ir neturite refresh_token, todėl vieną dieną hakeris gaus šį access_token ir jis galės pasiekti visus saugomus išteklius!

Bet jei turite atnaujinimo_priešą, prieigos laikas yra trumpas, todėl įsilaužėlis sunku nulaužti „access_token“, nes po kurio laiko jis taps negaliojančiu. „Access_token“ galima atkurti tik naudojant ne tik „refresh_token“, bet ir „client_id“ ir „client_secret“, kurių įsilaužėlis neturi.

4
03 окт. atsakymas pateikiamas Tạ Anh Tú 03 okt. 2018-10-03 07:59 '18, 07:59 2018-10-03 07:59

Pirma, klientas yra autentifikuotas autorizacijos serveryje, suteikiant leidimą.

Tada klientas prašo saugomo išteklių išteklių serverio, pateikdamas prieigos raktą.

Išteklių serveris tikrina prieigos raktą ir suteikia saugomą išteklių.

Klientas prašo ištekliaus serveryje saugomo šaltinio, pateikdamas prieigos raktą, kur išteklių serveris jį tikrina ir tarnauja užklausai, jei jis galioja. Šis veiksmas tęsiamas tol, kol baigsis prieigos raktas.

Pasibaigus prieigos raktui, klientas autentifikuoja su autorizacijos serveriu ir prašo naujo prieigos ženklo, pateikdamas atnaujinimo raktą. Jei prieigos raktas negalioja, išteklių serveris klientui siunčia klaidingą atsakymą į raktą.

Klientą atpažįsta autorizacijos serveris, pateikdamas atnaujinimo raktą.

Tada autorizacijos serveris tikrina atnaujinimo raktą, patvirtina klientą ir išduoda naują prieigos raktą, jei jis yra galiojantis.

0
07 сент. Atsakymą pateikė user8288060 07 sep . 2017-09-07 18:33 '17, 18:33 pm 2017-09-07 18:33

„Google Chrome“ sukūriau „SAML“, „WS-Federation“ ir „OAuth Tracer“ plėtinį: https://chrome.google.com/webstore/detail/rcfederation-saml-ws-fed/hkodokikbjolckghdnljbkbhacbhpnkb

Naudodami plėtinį, galite lengvai ištaisyti / sekti „pranešimus“, naudojamus ten esančiuose protokoluose.

0
21 дек. Atsakymą pateikė Rasmus Christiansen gruodžio 21 d. 2018-12-21 20:21 '18, 8:21 val. 2018-12-21 20:21

Nors atnaujinimo raktas yra saugomas autorizacijos serveryje. Prieigos raktas yra savarankiškas, todėl išteklių serveris gali jį patikrinti, neišsaugodamas, o patikrinimo atveju išsaugo paieškos pastangas. Kitas klausimas, kurio trūksta diskusijoje, yra rfc6749 # page-55