Каква е целта на типа имплицитно разрешение за предоставяне в OAuth 2?

Не знам дали просто имам някакъв вид сляпо петно ​​или какво, но прочетох спецификацията на OAuth 2 много пъти и прегледах архивите на пощенските списъци и все още не съм намерил добро обяснение защо имплицитното предоставяне е разработен поток за получаване на токени за достъп. В сравнение с предоставянето на код за оторизация, изглежда просто се отказва от удостоверяването на клиента без много убедителна причина. Как е това "оптимизирано за клиенти, внедрени в браузър, използващ скриптов език" (да цитирам спецификацията)?

И двата потока започват еднакво (източник: http://tools.ietf.org/html/draft-ietf-oauth-v2-22):

  1. Клиентът инициира потока, като насочва потребителския агент на собственика на ресурса към крайната точка за оторизация.
  2. Сървърът за оторизация удостоверява собственика на ресурса (чрез потребителския агент) и установява дали собственикът на ресурса предоставя или отказва заявката за достъп на клиента.
  3. Assuming the resource owner grants access, the authorization server redirects the user-agent back to the client using the redirection URI provided earlier (in the request or during client registration).
    • The redirection URI includes an authorization code (Authorization code flow)
    • URI адресът за пренасочване включва токена за достъп във фрагмента на URI (имплицитен поток)

Тук потоците се разделят. И в двата случая URI за пренасочване в този момент е към някаква крайна точка, хоствана от клиента:

  • В потока на кода за оторизация, когато потребителският агент удари тази крайна точка с кода за оторизация в URI, кодът в тази крайна точка обменя кода за оторизация заедно със своите клиентски идентификационни данни за токен за достъп, който след това може да използва при необходимост. Може например да го запише в уеб страница, до която скрипт на страницата може да има достъп.
  • Неявният поток пропуска напълно тази стъпка за удостоверяване на клиента и просто зарежда уеб страница с клиентски скрипт. Тук има сладък трик с URL фрагмента, който предпазва токена за достъп от прекалено много предаване, но крайният резултат е по същество същият: хостваният от клиента сайт обслужва страница с някакъв скрипт в нея, който може да грабне токена за достъп .

Оттук и въпросът ми: какво се печели тук чрез пропускане на стъпката за удостоверяване на клиента?


user-agent oauth-2.0 oauth
person Dan Taflin    schedule 22.09.2011    source източник
comment
Разгледайте това: ibm.com/developerworks/wikis/display/   -  person Håvard Geithus    schedule 20.07.2012
comment
Линкът в предишния коментар е мъртъв. Ето го актуализиран   -  person AndrewR    schedule 23.05.2014
comment
Прочетох всички отговори тук, но все още не разбирам как неизискването на частна клиентска тайна за получаване на токен за достъп може да бъде сигурно. Да кажем, че TrustedAppDeveloper пуска TrustedPopularApp, което позволява на потребителите да му дават разрешения (да речем чрез Twitter oauth), използвайки имплицитно разрешение. Ако съм EvilAppDeveloper, какво ме спира да направя приложение, което предава TrustedPopularAppId като client_id в имплицитна заявка за предоставяне и след това да извършва действия (като спам на емисия) от името на потребителя, които сега изглеждат така, сякаш идват от TrustedPopularApp ?   -  person adevine    schedule 03.02.2015
comment
Чудя се същото като адевин. Но най-вероятно приложенията, които изискват косвена заявка за безвъзмездни средства, нямат нужда от повече удостоверяване, тъй като всички получават?   -  person Mave    schedule 24.02.2015
comment
@adevine Това, което би попречило на EvilApp във вашия сценарий да се удостовери в Twitter като TrustedPopularApp е, че не може да получи обратните повиквания от Twitter, те винаги ще бъдат изпращани до URI, който е дефиниран при регистриране на клиентския идентификатор   -  person Ivan    schedule 29.03.2015
comment
Възможен дубликат на Какво каква е разликата между двата работни процеса? Кога да използвате потока на кода за оторизация?   -  person Michael Freidgeim    schedule 10.09.2017

Отговори (12)


arrow_upward
201
arrow_downward

Ето моите мисли:

Целта на кода за удостоверяване + токена в потока на кода за оторизация е, че токенът и тайната на клиента никога няма да бъдат изложени на собственика на ресурса, защото пътуват от сървър към сървър.

От друга страна, имплицитният поток на грант е за клиенти, които са внедрени изцяло с помощта на javascript и се изпълняват в браузъра на собственика на ресурса. Не се нуждаете от код от страната на сървъра, за да използвате този поток. След това, ако всичко се случи в браузъра на собственика на ресурса, няма смисъл вече да се издава код за удостоверяване и тайна на клиента, тъй като токенът и тайната на клиента все още ще се споделят със собственика на ресурса. Включването на код за удостоверяване и тайна на клиента просто прави потока по-сложен, без да добавя повече реална сигурност.

Така че отговорът на "какво е спечелено?" е "простотия".

person Philip Peshin    schedule 07.10.2011
comment
Благодаря. Това е добър момент, че в потока на кода за оторизация собственикът на ресурса никога не трябва да вижда маркера за достъп, докато в клиентите на javascript това е неизбежно. Тайната на клиента все още може да се пази от клиентите на javascript, използвайки потока на кода за оторизация, обаче: след удостоверяване и получаване на токен за достъп кодът от страната на сървъра ще предаде токена на клиента на javascript. Това, което сега виждам обаче, е, че имплицитният поток на грант позволява разпространението на javascript oauth SDK, като този на Facebook, освобождавайки разработчиците от необходимостта да пишат напълно свой собствен oauth код. - person Dan Taflin; 07.10.2011
comment
Може би бих добавил, че потокът от кодове за оторизация позволява на клиентите да съхраняват токените и да ги използват повторно. В имплицитния поток не винаги имате тази опция и като такъв имплицитният поток е прагматичен избор между ниво на сигурност и удобство. - person PålOliver; 03.06.2013
comment
@PålOliver защо не можем да съхраним токена, който получаваме от имплицитния поток, както правим с потока на кода за оторизация? - person Rishabh Agrawal; 15.04.2017
comment
@ANinJa в неявния поток токенът се съхранява в потребителския агент (браузър), но в потока auth.code токенът може да се съхранява на клиентския сървър. Трябва да внимавате как съхранявате токена в потребителския агент (браузър) в имплицитния поток. Естествено токенът трябва да се съхранява при удостоверяване. сървър и в двата случая. - person PålOliver; 18.04.2017
comment
Това отговаря само наполовина, а какво е изгубено? - person EralpB; 01.05.2017
comment
Какво имате предвид под Не се нуждаете от код от страната на сървъра, за да използвате този поток.? - person Yurii N.; 29.06.2017
comment
Не мисля, че това е изчерпателен отговор, имплицитният поток не е предназначен да спечели предимство от простотата, а да компрометира проблемите със сигурността с приложението от страна на клиента. Auth code, заедно с client_id и client_secret се използват за идентифициране на доверени клиенти, които могат да опресняват токени за продължително влизане и за офлайн влизане. Въпреки това в приложение от страна на клиента няма начин да се регистрира всеки клиент, следователно опростеният имплицитен тип предоставяне за временен достъп до потребителска информация - person Chen Xie; 13.07.2017
comment
Включването на клиентската тайна не само прави потока по-сложен, но го прави по-малко сигурен. Тайната на клиента не е тайна, ако трябва да бъде изброена в кода от страна на клиента и следователно ще бъде изложена в интернет. Ако вашият клиентски идентификатор се използва само в неявни потоци, това не е проблем. Но ако се използва и другаде във вашата платформа за предоставяне на означения за опресняване или код за оторизация, тогава разкриването на съответната тайна е голям проблем. - person rurouniwallace; 06.11.2018
comment
Съгласен съм с отговора. спецификация на OAuth гласи: имплицитното разрешение е опростен поток на код за оторизация и Неявните безвъзмездни средства подобряват отзивчивостта и ефективността на някои клиенти, тъй като намаляват броя на двупосочните пътувания, необходими за получаване на токен за достъп. - person Lu55; 30.07.2019

arrow_upward
97
arrow_downward

Там е от съображения за сигурност, а не за опростяване.

Трябва да имате предвид разликата между потребителския агент и клиента:

Потребителският агент е софтуерът, чрез който потребителят („собственикът на ресурс“) комуникира с други части на системата (сървър за удостоверяване и сървър за ресурси).

Клиентът е софтуерът, който иска достъп до ресурсите на потребителя на сървъра за ресурси.

В случай на отделен потребителски агент и клиент Предоставянето на код за оторизация има смисъл. напр. потребителят използва уеб браузър (user-agent), за да влезе със своя Facebook акаунт в Kickstarter. В този случай клиентът е един от сървърите на Kickstarter, който обработва влизанията на потребителите. Този сървър получава токена за достъп и токена за опресняване от Facebook. По този начин този тип клиент, считан за „сигурен“, поради ограничения достъп, токените могат да бъдат запазени и Kickstarter може да има достъп до ресурсите на потребителите и дори да опреснява токените за достъп без намеса на потребителя.

Ако потребителският агент и клиентът са свързани (напр. собствено мобилно приложение, javascript приложение), може да се приложи работният процес за имплицитно упълномощаване. Той разчита на присъствието на собственика на ресурса (за въвеждане на идентификационните данни) и не поддържа токени за опресняване. Ако този клиент съхранява токена за достъп за по-късна употреба, това ще бъде проблем със сигурността, тъй като токенът може лесно да бъде извлечен от други приложения или потребители на клиента. Липсата на маркера за опресняване е допълнителен намек, че този метод не е предназначен за достъп до потребителските ресурси в отсъствието на потребителя.

person artkoenig    schedule 03.09.2014
comment
Виждам, че браузърът ми е влизал в акаунта ми в Google от месеци. И така, токен за достъп на Google използва ли в браузъра или токен за достъп с дълго време на изтичане? каква е разликата в използването между токен за достъп с дълго време на изтичане и токен за достъп? всеки друг клиент може да улови токена за достъп и да го използва, когато собственикът на ресурса не присъства. - person Mohammad Nikravan; 15.12.2016
comment
Предполагам, че имате предвид разликата между токен за опресняване и токен за достъп с дълго време на изтичане? Токенът за опресняване не трябва да се записва в несигурни сценарии, но все пак можете да запазите своя токен за достъп (напр. в локалното хранилище на браузъра). Сигурността се постига чрез поддържане на продължителността на живота на вашето означение за достъп възможно най-ниско, но все пак удобно за вашите потребители (напр. можете да ги излезете автоматично след x минути неактивност). Ако използвате токени за достъп с дълъг живот, на практика правите токените за опресняване остарели. - person artkoenig; 23.01.2017
comment
Благодаря за обяснението, но имам и друго объркване. Не разбирам защо се нуждаем от потока на кода за оторизация. Можем да постигнем същия резултат на сървъра чрез имплицитен поток (access_token) и токен за опресняване. Изглежда единственото съображение за сигурност на имплицитния поток е, че access_code трябва да има кратък живот, така че да не може да се използва от сървър към сървър. Добре, но токенът за опресняване решава този проблем. Защо трябва да използваме поток от auth_code и да поискаме access_token от този токен на сървър, за да получим access_code, докато можем да постигнем същия резултат с refresh_token? - person Mohammad Nikravan; 24.01.2017
comment
токенът може лесно да бъде извлечен от други приложения Как? - person mvmn; 09.03.2017
comment
@MohammadNikravan потърсете отговора в stackoverflow.com/q/13387698/355438 - person Lu55; 30.07.2019

arrow_upward
61
arrow_downward

Обичайното обяснение е, че неявното предоставяне е по-лесно за прилагане, когато използвате JavaScript клиент. Но мисля, че това е грешният начин да се гледа на нещата. Ако използвате JavaScript клиент, който изисква защитени ресурси директно чрез XMLHttpRequest, имплицитното предоставяне е единствената ви опция, въпреки че е по-малко сигурна.*

Предоставянето на код за оторизация осигурява допълнителна сигурност, но работи само когато имате уеб сървър, който изисква защитените ресурси. Тъй като уеб сървърът може да съхранява токена за достъп, поемате по-малък риск маркерът за достъп да бъде изложен на Интернет и можете да издадете токен, който трае дълго време. И тъй като уеб сървърът е надежден, може да му бъде даден "токен за опресняване", така че да може да получи нов маркер за достъп, когато старият изтече.

Но – и това е момент, който лесно се пропуска – сигурността на потока на кода за оторизация работи само ако уеб сървърът е защитен със сесия, която се установява с удостоверяване на потребителя (влизане). Без сесия, ненадежден потребител би могъл просто да прави заявки към уеб сървъра, използвайки client_id, и би било същото, както ако потребителят имаше токена за достъп. Добавянето на сесия означава, че само удостоверен потребител има достъп до защитените ресурси. client_id е само "идентичността" на JS webapp, а не удостоверяване на споменатото webapp.

Това също означава, че можете да прекратите сесията преди OAuth токенът да изтече. Няма стандартен начин за невалидност на маркер за достъп. Но ако вашата сесия изтече, токенът за достъп е безполезен, тъй като никой не го знае освен уеб сървъра. Ако ненадежден потребител получи достъп до вашия сесиен ключ, той ще има достъп до защитените ресурси само докато сесията е валидна.

Ако няма уеб сървър, трябва да използвате имплицитното разрешение. Но това означава, че маркерът за достъп е изложен на интернет. Ако ненадежден потребител получи достъп до него, той може да го използва, докато не изтече. Това означава, че те ще имат достъп до него за по-дълго време, отколкото с предоставяне на код за оторизация. Така че може да помислите да накарате токена да изтече по-рано и да избягвате да давате достъп до по-чувствителни ресурси.

*РЕДАКТИРАНЕ: Напоследък хората препоръчват да избягвате използването на имплицитно разрешение, дори в уеб приложения без сървър. Вместо това можете да използвате предоставения код за оторизация, конфигуриран с празна тайна, заедно с PKCE. Предоставянето на код за удостоверяване избягва съхраняването на токена за достъп в хронологията на вашия браузър и PKCE избягва излагането му, ако някой отвлече URL адреса за пренасочване, за да открадне кода за удостоверяване. В този случай ще трябва сървърът да избегне връщането на означение за опресняване, тъй като вашият клиент вероятно не може да го съхранява сигурно. И трябва да издаде токен за достъп със същите ограничения, споменати по-горе.

person JW.    schedule 14.09.2013

arrow_upward
21
arrow_downward

Това се свежда до: Ако потребител изпълнява базирано на браузър или „публично“ (JavaScript) уеб приложение без компонент от страна на сървъра, тогава потребителят имплицитно се доверява на приложението (и на браузъра, където работи, потенциално с други базирани на браузър приложения...).

Няма отдалечен сървър на трета страна, а само сървър за ресурси. Няма полза от кода за оторизация, защото няма друг агент освен браузъра, действащ от името на потребителя. Няма полза за клиентските идентификационни данни по същата причина. (Всеки клиент може да се опита да използва този поток.)

Последиците за сигурността обаче са значителни. От http://tools.ietf.org/html/rfc6749#section-10.3:

Когато се използва имплицитният тип разрешение, токенът за достъп се предава във фрагмента на URI, което може да го изложи на неупълномощени страни.

От http://tools.ietf.org/html/rfc6749#section-10.16:

Собственикът на ресурс може доброволно да делегира достъп до ресурс, като предостави токен за достъп на злонамерен клиент на атакуващ. Това може да се дължи на фишинг или някакъв друг претекст...

person Will    schedule 24.04.2013
comment
какво имате предвид под публично (JavaScript) уеб приложение без компонент от страна на сървъра? Как може да има уеб приложение без сървър? - person ANewGuyInTown; 29.05.2019
comment
@ZammyPage, това би било това, което често се нарича приложение за една страница (SPA). Цялото приложение се сервира от статичен ресурс. След това Javascript в приложението динамично осъществява достъп до всички ресурси, от които има нужда, до каквито и сървъри за ресурси да има достъп. Няма сървър, който да генерира съдържанието на клиента: javascript в клиента модифицира DOM според нуждите, за да представи ресурсите, до които е осъществил достъп. - person Elroy Flynn; 03.07.2019
comment
Има просто, но значимо предимство: ако съхранявате регистрационни файлове на сървъра и използвате потока на кода за оторизация, много вероятно всички кодове ще бъдат невалидни, ако регистрационните файлове изтекат. Ако съхранявате токени за достъп, можете директно да се представяте за потребителски сесии. - person Délisson Junio; 01.10.2020

arrow_upward
13
arrow_downward

Не съм сигурен, че разбирам правилно отговора и коментара на Дан. Струва ми се, че отговорът е посочил някои факти правилни, но посочва точно това, което OP поиска. Ако разбирам правилно, основното предимство на имплицитния поток на грант е, че клиент като JS приложение (напр. разширение за Chrome) не трябва да разкрива тайната на клиента.

Дан Тафлин каза:

...в потока на кода за оторизация собственикът на ресурса никога не трябва да вижда токена за достъп, докато в клиентите на javascript това е неизбежно. Въпреки това тайната на клиента все още може да се пази от клиенти на javascript, използващи поток от код за оторизация.

Може би не съм ви разбрал погрешно, но клиентът (JS приложение в този случай) трябва да предаде идентификационните данни на клиента (клиентски ключ и тайна) на сървъра за ресурси в потока на кода за оторизация, нали? Тайната на клиента не може да бъде "пазена от JS".

person tzuchien.chiu    schedule 17.09.2012
comment
Разбирам, че това е стар въпрос, но това е по-добър отговор от приетия. Причината за съществуването на Implicit Grant е, че клиентът на javascript не може да пази тайна и следователно не може да бъде удостоверен. Така че сървърът за оторизация трябва да разчита единствено на регистрацията на URI за пренасочване и потребителския агент за сигурност. Вие предавате токени за оторизация само на потребителския агент и само на конкретен URI за пренасочване, теоретично предотвратявайки прихващане (защото злонамерен потребител, който не притежава домейна на URI за пренасочване, не може да изпълни код в потребителския агент на този URI). - person gregates; 18.03.2016
comment
Наистина приетият отговор ме обърка. Накара ме да мисля, че не съм разбрал какво е client_secret! Този отговор и горният коментар са на място. - person Sarsaparilla; 19.08.2016

arrow_upward
9
arrow_downward

Въпреки че Implicit Grant е проектиран да поддържа приложения, които не могат да защитят клиент тайна, включително приложения на JavaScript от страна на клиента, някои доставчици прилагат алтернатива, използвайки вместо това код за оторизиране без клиентска тайна. OAuth 2.0 IETF RFC-6749 беше публикуван през 2012 г. и настоящите препоръки, някои скорошни дискусии са от 2017 г. .

Дискусията за 2017 г. в пощенския списък на IETF OAuth е достъпна от тези изпълнители:

Прочетете повече тук:

Имплицитният преди беше препоръчан за клиенти без тайна, но беше заменен от използването на предоставяне на код за оторизация без тайна.

...

По-рано се препоръчваше приложенията, базирани на браузър, да използват „неявния“ поток, който незабавно връща токен за достъп и няма стъпка за обмен на токени. Във времето, откакто спецификацията беше първоначално написана, най-добрата практика в индустрията се промени, за да се препоръча потокът на кода за оторизация да се използва без тайната на клиента. Това предоставя повече възможности за създаване на защитен поток, като например използване на параметъра състояние. Препратки: Redhat, Deutsche Telekom, Smart Health IT.

Преминаването към Auth Code без Client Secret от Implicit Grant също се споменава за мобилни приложения тук:

person Grokify    schedule 28.05.2018
comment
Мисля, че трябва да внимавате с тази препоръка. Това беше препоръчано в ръководството за собствени приложения, а не за спа центрове. За съжаление няма добри насоки за SPA, както е документирано в много от онлайн дискусиите, форумите и дори в пощенския списък на oauth-wg. - person Tom; 06.09.2018
comment
Препоръката за преминаване към код за удостоверяване без тайна от имплицитно предоставяне е препоръка както за SPA, така и за мобилни приложения, но моята извадка по-горе е специфична за SPA. Посочената статия използва подобен текст както за SPA, така и за мобилни приложения, но с езика базирани на браузър приложения за мобилни устройства и собствени приложения в съответния текст. Също така референциите за Redhat, DT, Smart Health IT са специфични за SPA и не са включени в бележката за мобилни приложения. Добавих дълбока връзка към SPA в отговора, за да направя това по-лесно за намиране. Моля, публикувайте няколко връзки към дискусиите, които споменавате. - person Grokify; 18.09.2018
comment
Сравнително скорошна (2018 г.) дискусия oauth-wg може да бъде намерена тук ietf.org/mail-archive/web/oauth/current/msg18020.html. RFC 8252 е за собствени приложения, тъй като заглавието предполага OAuth 2.0 за собствени приложения. Препратките към Redhat, DT, Smart Health IT са отговори на дискусия в пощенски списък, а не rfc, работен проект и т.н. - person Tom; 18.09.2018

arrow_upward
4
arrow_downward

В имплицитния поток, ако браузърът на потребителя е повреден (зло разширение/вирус), тогава повредата получава достъп до ресурсите на потребителя и може да направи лошите неща.

В потока на удостоверяване корупцията не може, защото не знае тайната на клиента.

person Pace    schedule 13.04.2017

arrow_upward
3
arrow_downward

в допълнение към другите отговори също така е важно да се осъзнае, че имплицитният профил позволява поток само на предния канал, за разлика от потока на кода за оторизация, който изисква обратно извикване към сървъра за оторизация; това става очевидно в OpenID Connect, който е SSO протокол, изграден върху Auth 2.0, където имплицитният поток наподобява доста популярното свързване на SAML POST, а потокът на кода за оторизация прилича на по-малко разпространеното свързване на SAML Artifact

person Hans Z.    schedule 18.11.2014

arrow_upward
2
arrow_downward

https://tools.ietf.org/html/rfc6749#page-8

имплицитно

Неявното разрешение е опростен поток от код за оторизация, оптимизиран за клиенти, внедрен в браузър, използващ скриптов език като JavaScript. В имплицитния поток, вместо да издаде на клиента код за оторизация, на клиента се издава директно токен за достъп (като резултат от оторизацията на собственика на ресурса). Типът разрешение е имплицитно, тъй като не се издават междинни идентификационни данни (като код за оторизация) (и по-късно използвани за получаване на токен за достъп).

Когато издава токен за достъп по време на имплицитния поток на разрешение,
сървърът за оторизация не удостоверява клиента. В някои
случаи самоличността на клиента може да бъде потвърдена чрез URI за пренасочване
, използван за доставяне на токена за достъп до клиента. Токенът за достъп може да бъде изложен на собственика на ресурса или други приложения с достъп до потребителския агент на собственика на ресурса.

Неявните безвъзмездни средства подобряват отзивчивостта и ефективността на някои
клиенти (като клиент, внедрен като приложение в браузъра),
тъй като намалява броя на двупосочните пътувания, необходими за получаване на
маркер за достъп.

person Rzv Razvan    schedule 14.10.2017

arrow_upward
1
arrow_downward

Мисля, че Уил Кейн отговори на това, когато каза „Няма полза за идентификационните данни на клиента по същата причина. (Всеки клиент може да се опита да използва този поток.)“ Също така помислете, че redirect_uri за имплицитния поток може би „localhost“-без обратно извикване се прави от сървъра за оторизация за имплицитния поток. Тъй като няма начин да се доверите предварително на клиента, потребителят ще трябва да одобри освобождаването на потребителски искове.

person Mike Schwartz    schedule 17.12.2014

arrow_upward
1
arrow_downward

Неявното предоставяне позволява получаване на токени от Крайна точка за упълномощаване с GET. Това означава, че сървърът за оторизация не трябва да поддържа CORS.

Ако това не е проблем и няма други проблеми, свързани с негъвкавостта на сървъра за оторизация (напр. токените за опресняване не са по избор по някаква причина), тогава потокът от код за оторизация е предпочитаният, дори за публични клиенти, според скорошни тенденции в индустрията и поне до този (текущ) екземпляр на официална чернова.

Исторически е имало други причини за прилагане на имплицитния поток, но изглежда, че в момента те са надделени от предимствата на сигурността, предоставяни от предоставянето на код за оторизация, включително:

  • опция за доставяне и използване на токените по обратен канал за поверителни клиенти
  • неизлагане на токени в хронологията на браузъра за публични клиенти
  • прекъсване на неоторизиран поток преди издаване на токени - с PKCE, за "всички видове OAuth клиенти"
person ko la    schedule 04.10.2018

arrow_upward
0
arrow_downward

Току-що се сблъсках с някаква статия за OAuth 2.0. Авторът заявява, че причината зад имплицитния поток е, че JS приложенията са били много ограничени в заявките:

ако се чудите защо имплицитният тип е включен в OAuth 2.0, обяснението е просто: Политика за същия произход. Тогава на предните приложения не беше разрешено да изпращат заявки до различни хостове, за да получат токена за достъп с помощта на код. Днес имаме CORS (Cross-Origin Resource Sharing).

https://medium.com/securing/what-is-going-on-with-oauth-2-0-and-why-you-should-not-use-it-for-authentication-5f47597b2611

person Lu55    schedule 30.07.2019