Реализовал уже 5 разных аутентификаций (VK, OK, MailRu, FB, Instagram), но до сих пор не пойму, зачем мне для получения каких-нибудь данных с помощью API получать CODE, который затем меняется на Access_token? нельзя ли после введения юзером своих данных в системе социальной сети сразу отдать мне access_token? Какого Макара я должен делать запрос аж 3 раза? Ну по сути мне то ладно, я один раз описал пару классов, которые это делают и забыл. Но желание понять какой в этом смысл не дает покоя. Ведь, согласитесь, было бы удобно и вполне логично выдать сразу access_token, который можно было дальше использовать. А необходимый scope указать при единственном запросе.
https://oauth.net/2/ Читай, там где-то есть ответ на твой вопрос. Лично я считаю, что это просто способ отделить пользовательскую авторизацию от серверной. У тебя есть более простой способ это сделать? Напиши им, обязательно
так вот все дело в нюансах, я читал статью на хабре, но она не раскрывает нюансов, почему есть дополнительный запрос. Там на писано что это "наиболее сложный, но необходимый способ" при серверной авторизации. Но чтобы понять это мне необходимо понять, как я будучи хакером мог бы что-то где-то подделать, имей схема ни 3 а 2 запроса. И как обмен code на access_token решает эту проблему моего злодейства. Если бы я был полиглотом, конечно бы указанную тобой документацию покурил, но когда хочется чего-то побыстрее и человеческим языком - обычно обращаешься на форум вроде этого. Простыми словами было бы здорово! Например обычный пользователь Вася нажимает кнопочку "войти с помощью Вконтакте", запрос уходит сервису Oauth вконтакте, оттуда редиректит на указанную страницу... Включи в этот рассказ злого хакера Петю. И тогда все ляжет на свои полочки. Я и другие читатели поймем суть. Образный рассказ, лучше не придумать. Я вот кпримеру не пойму, почему сразу в запросе нельзя указать что авторизация типа сервер-сервер, чтобы сервер авторизации вернул сразу токен без последующего обмена.
access_token нужен только Приложению и Серверу, но не Юзеру. чтобы они(Приложение и Сервер) поняли друг друга - о каком клиенте идет речь и о каких именно правах..... У клиента не должно светиться никаких токенов. Потому ему и дают только CODE, который он отдает тут же Приложению и всё, дальше уже взаимодействуют Приложение и Сервер. что и как они там делают - Юзера уже не интересует. Это логично, безопасно и гибко. Завтра расширят протокол, добавят чтото еще хитрое, что вынудит Приложение и Сервер отмениваться 20-ю запросами(например), но для клиента ничего не изменится. он также будет давать права, получать код и отдавать его Приложению,а что там дальше уже не его дело.
ок мне этот алгоритм понятен. И его смысл я тоже понимаю. и мне в то же время непонятно, почему нельзя получить access_token одним запросом? Либо сразу требуемую информацию. Ведь это реализуемо: элементарно: после выдачи пользователем прав, сервер авторизации сразу выдает запрошенную в запросе информацию. Образно: юзер Вася нажимает на кнопочку "зарегистрироваться", приложение редиректит его страничку выдачи прав, Вася прочитал что приложение будет знать его емейл и идентификатор, подумал, свыкся с мыслью что ничего страшного, нажал "подтвердить". Сервер авторизации редиректит Васю обратно на какую-нибудь страницу сайта с $_POST данными (которые были указаны в get параметре, скажем метод API, fields). Хотя, чувствую, я шибко придрался, по сути это все не так важно. И объяснить сложно, поскольку есть дофига технических лазеек, в которые долго углубляться. Я просто думал что объяснение простое.
6ля в отличии от прямой авторизации с устройства залогенном на нужном сервисе, серверная дает доступ с определенного url и переходит туда. Там его должны подтвердить. Че тупишь. Если бы они просто по запросу выдавали токен на любой адрес, то чтобы было, ты сам включи мозг )))
6ля, включил мозг, все равно не сходится: в настройках приложения на сервере аутентификации(что создавали в девелоперском кабинете) прописывались разрешенные домены. Значит приложение (то что создано в девелоперском акке) знает с какими урлами разрешено работать. Так разве Oauth сервер не может проверить все это еще на этапе выдачи разрешений юзером? Он же уже знает к какому приложению (в дев кабинете) идет обращение, и знает разрешенные домены. Так пусть и редиректит куда надо.
Там в настройках это все для openapi вроде, чтобы злоумышленникам ничего не ушло на левые сайты, с помощью банального джаваскрипта А серверная идет по этой спецификации, которую я скинул во втором посте. Я вовсе не претендую на истину, но думаю, что я близок к ней
@yurri_87 код (code) - одноразовый. Токен (access token) - многоразовый. Мы ведь говорим о авторизации серверного приложения, верно? Сервис редеректит браузер пользователя на callback-урл приложения, с кодом code в адресе. Приложение использует этот code для POST-запроса к сервису и получения токена. Несложно заметить, что code проходит через браузер, а токен передается прямиком между серверами. По одному и тому же code нельзя дважды получить токен. Таким образом, перехватывать code бесполезно (либо надо успеть его использовать быстрее, чем это сделает приложение). А если бы через браузер гуляли токены, в частности через GET (а сделать редирект с POST-передачей без использования JS невозможно), то их бы часто воровали и использовали для взлома пользователей. Такие дела.
Спасибо! это больше чем наполовину прояснило ситуацию. Но мысль о том, что можно проще не покидает. Смирюсь.