Принцип работы Oauth2
1,00
р.
Здравствуйте, сразу прошу извинить если вопрос глупый. Собственно сейчас разбираюсь с возможными вариантами авторизации с помощью REST API. Сейчас все социальные сети используют авторизацию OAuth/OAuth2. Прочитав немало статьей, все равно не очень хорошо отложилось в голове и есть много сомнений, что правильно понимаю.
Первое что это главные игроки, я не буду называть как в документации сказано, назову как понимаю.
Пользователь. Это владелец аккаунта который имеет доступ к каким-то ресурсам. Например Facebook/Twitter. Сервер авторизации OAuth/OAuth2. Это непосредственно сервер который производит выдачу разрешений на доступ к ресурсам(токены, "секреты"). Если взять пример из реальной жизни, то oauth.vkontakte.ru. Сервер расположен по такому домену(поддомен) сервера социальной сети Вконтакте. Сервер ресурсов. Это собственно сервер на котором хранятся данные для доступа к которым все это (Oauth авторизация) была придумана. Это могут быть различные данные, например фотки, музыка, записи из социальной сети. Приложение, может не всегда быть всем общепринятым приложением (программой) это может быть, а обычно так часто и есть, сервер. С помощью этого приложения пользователь хочет без пароля получить какие-то данные которыми он владеет. Например возьмем пример вконтакте или твитер. Чтобы использовать их API нужно зарегистрировать приложение у них на сайте ( в разделе разработчик), это подразумевает получения каких-то индентификаторов/ключей ... строк текста, с помощью которых можно запрашивать у пользователя разрешение на доступ к данным. Например, чтобы делать авторизацию на сайте через Вконтакте, нужно зарегистрировать приложение, получить ключи/токен, и в тот момент когда пользователь хочет выполнить вход через Вконтакте пересылать этот ключ на сервер. Или же приложение для мобильного устройства через которое пользователь будет производить вход и доступ к данным.
Теперь, как происходит авторизация, в моем понимании.
Допустим пользователь Х хочет зайти на сайт S через социальную сеть вконтакте. Разработчик сайта заранее предусмотрел возможность авторизации через социальные сети и зарегистрировал свой сайт как приложение вконтакте, получил ключик/токен. Пользователь, клацает на красивую кнопочку "Вход через Вконтакте". Что в этот момент происходит. Сайт(сервер) берет ранее полученный ключик, прикрепляет его к запрос и идет по ссылке, oauth.vk.com. (Передавая свой ключ в GET параметрах или POST не столь важно). Сервер oauth.vk.com смотрит, так такое приложение есть в базе, значит можно доверять. Теперь интересный момент, если пользователь был ранее авторизирован Вконтакте,то ему показывают всплывающее окошко, "Вы разрешаете приложению.....". А вот если пользователь ранее не производил вход Вконтакте, то ему сначала предлагают ввести свой пароль и логин, а уже затем спросят разрешает ли он приложению...... После этого если пользователь нажал "Да", то сервер oauth генерирует токен доступа, который является своеобразным временным паролем. Записывает в базу сам токен и например дату истечения. Возвращает этот токен серверу (сайт с которого пользователь хотел войти ВК) по адресу указанному в Callback, сервер смотрит, забирает токен записывает себе в базу данных рядом с именем пользователя. Если же нет, получает отказ в каком-то виде. Получив токен "приложение" имеет доступ к данным пользователя ( если нету ограничений на стороне сервера ресурсов). По сути если написать таким образом вредоносную программу, то можно после получения токен слить или удалить всю информацию пользователя. Имея данный токен. Мы можем использовать его в нескольких целях : использую как подтверждение того, что пользователь прошел авторизацию и теперь давать ему доступ к данным на нашем сайте (сайт с которого пользователь нажимал кнопку "Войти вконтакте") постоянно проверяя токен при доступе к приватным ресурсам на нашем сайте. То есть тот же пароль или сессия на стороне сервера (кукисы ...). Или же с помощью нашего сайта делать что-то на странице пользователя вконтакте, загружать фото, делать посты......
Теперь вопросы которые возникли у меня, кроме главного (правильно ли я вообще понимаю).
Если перехватить токен, то можно использовать его как тот же пароль. В чем тогда преимущество? Можно ограничить ресурсы разными токенами? Он временный и через некоторое время уже будет недействительным, но если злоумышленник успеет сделать что-то раньше ? То есть передавать токен как и пароль нужно в пост запросе по HTTPS протоколу, чтобы защищать его как тот же пароль? Если я использую токен от Вконтакте как авторизацию на своем сайте, то каким образом поучать новый токен по истечению срока действия старого, заново запрашивать " Вы разрешаете приложению .... " через oauth сервер. Такого не встречал на сайтах, обычно один раз разрешил и все. Данные способ авторизации удобен когда у пользователя есть какой-то глобальный аккаунт на доверенном сервере.Если же нужна авторизация на своем сервере только и без сторонних oauth серверов, следует использовать похожий принцип просто, при первой авторизации один раз передавать логин и пароль по HTTPS и получать токен уже непосредственно у сервера. Допустим интернет магазин и клиент Android.Первый раз логин и пароль, в ответ прилетает токен и доступ к API производить уже передавая этот токен. Регистрация приложения является дополнительным уровнем безопасности, то есть чтобы не все могли попросить пользователя разрешить им доступ и получить токен. Если приложение допускает авторизацию, как прямо на самом сервер (интернет магазин) так и через OAuth (вконтакте), то кто должен контроллировать время жизни токена во втором случае. В первом случае мы работаем непосредственно с нашими сервером(интернет магазин), а во втором случае мы передаем и используем токен полученный от внешнего сервера OAuth (vkontakte) каким образом нам нужно обновлять токен, просить об этом у oauth.vk.com или нам в данном Вконтакте больше не нужен, после выдачи первого токена и теперь сами на стороне сервера интернет магазина генеируем новые токены ?
Всем спасибо, кто дочитал это.
Скажите, правильно ли я вообще понимаю принцип работы? Если нет, то скажите пожалуйста где и что не так.
Спасибо всем огромное
Ответ
В принципе правильно, хоть и запутанно немного описываете. Там всё проще )
По остальным вопросам:
Нет, не так-же. Разница в правах. Для авторизации обычно не требуют прав больших чем "возможность получить имя и фамилию пользователя". В диалоге аутентификации приложения пользователь видит все права, которые оно у него требует, и если не согласен, то может отказаться. Ну и на уровне API обычно не предусматривают никаких критичных действий. Скажем, пароль или e-mail пользователя по access-токену практически нигде нельзя поменять. Да, очень желательно. Ну и большинство сервисов вообще не позволяют работать через незашифрованное соединение. Впрочем, в случае explict-авторизации, кроме как между сервисом и вашим сервером access-токен никуда не передается. Т.е. при использовании незашифрованного соединения, перехватить токен может может только ваш хостер, либо провайдер вашего хостера. Что впрочем, тоже потенциально может быть неприятным. Делают обычно по другому - через запрос нового access-токена, используя статичный refresh-токен и старый access-токен. Пользователь при этом ничего не видит, но access-токены постоянно заменяются на новые. У кого-то это происходит раз в день, а у кого-то раз в пару часов. Скомпрометированные токены при этом естественно становятся недействительными. В случае получения запроса с некорректной комбинацией refresh-токена и access-токена, сервис автоматически должен сделать оба токена недействительными, ну и соответственно в этом случае пользователь увидит окошко аутентификации приложения заново. Но это если сервис вообще выдает refresh-токены. К сожалению они опциональны, и ВКонтакте не выдает их, в отличии от Google и Facebook. В этом случае можно только периодически запрашивать что-то доступное вашему приложению. После истечения срока токена, сервис будет выдавать в ответ ошибку 400 с error=invalid_grant - в этом случае приложение должно снова перекинуть пользователя на форму аутентификации приложения на сервисе, дабы получить новый access-токен. Да, так. Так многие и делают. По похожему принципу, кстати, работает авторизация на большинстве сайтов ещё со времен создания интернета. Логин-пароль передаются сервису только один раз, возвращается некий токен(например хеш чего-либо), он сохраняется в некое хранилище(например в cookies), ну и собственно этот токен используется используется для авторизации в последующие разы. Пресловутые же email и пароль по такому токену менять не позволяют. Не только. Основная цель регистрации приложений - дать возможность администрации отключить всё приложение разработчика в связи с выполнением приложением каких-то вредоносных действий, или в случае массовой компрометации access-токенов пользователей этого приложения. Нет, не на самом сервере приложения. Сервер приложения просто отправляет сервису запрос на refresh, и в ответ получает новый access-token.
Первое что это главные игроки, я не буду называть как в документации сказано, назову как понимаю.
Пользователь. Это владелец аккаунта который имеет доступ к каким-то ресурсам. Например Facebook/Twitter. Сервер авторизации OAuth/OAuth2. Это непосредственно сервер который производит выдачу разрешений на доступ к ресурсам(токены, "секреты"). Если взять пример из реальной жизни, то oauth.vkontakte.ru. Сервер расположен по такому домену(поддомен) сервера социальной сети Вконтакте. Сервер ресурсов. Это собственно сервер на котором хранятся данные для доступа к которым все это (Oauth авторизация) была придумана. Это могут быть различные данные, например фотки, музыка, записи из социальной сети. Приложение, может не всегда быть всем общепринятым приложением (программой) это может быть, а обычно так часто и есть, сервер. С помощью этого приложения пользователь хочет без пароля получить какие-то данные которыми он владеет. Например возьмем пример вконтакте или твитер. Чтобы использовать их API нужно зарегистрировать приложение у них на сайте ( в разделе разработчик), это подразумевает получения каких-то индентификаторов/ключей ... строк текста, с помощью которых можно запрашивать у пользователя разрешение на доступ к данным. Например, чтобы делать авторизацию на сайте через Вконтакте, нужно зарегистрировать приложение, получить ключи/токен, и в тот момент когда пользователь хочет выполнить вход через Вконтакте пересылать этот ключ на сервер. Или же приложение для мобильного устройства через которое пользователь будет производить вход и доступ к данным.
Теперь, как происходит авторизация, в моем понимании.
Допустим пользователь Х хочет зайти на сайт S через социальную сеть вконтакте. Разработчик сайта заранее предусмотрел возможность авторизации через социальные сети и зарегистрировал свой сайт как приложение вконтакте, получил ключик/токен. Пользователь, клацает на красивую кнопочку "Вход через Вконтакте". Что в этот момент происходит. Сайт(сервер) берет ранее полученный ключик, прикрепляет его к запрос и идет по ссылке, oauth.vk.com. (Передавая свой ключ в GET параметрах или POST не столь важно). Сервер oauth.vk.com смотрит, так такое приложение есть в базе, значит можно доверять. Теперь интересный момент, если пользователь был ранее авторизирован Вконтакте,то ему показывают всплывающее окошко, "Вы разрешаете приложению.....". А вот если пользователь ранее не производил вход Вконтакте, то ему сначала предлагают ввести свой пароль и логин, а уже затем спросят разрешает ли он приложению...... После этого если пользователь нажал "Да", то сервер oauth генерирует токен доступа, который является своеобразным временным паролем. Записывает в базу сам токен и например дату истечения. Возвращает этот токен серверу (сайт с которого пользователь хотел войти ВК) по адресу указанному в Callback, сервер смотрит, забирает токен записывает себе в базу данных рядом с именем пользователя. Если же нет, получает отказ в каком-то виде. Получив токен "приложение" имеет доступ к данным пользователя ( если нету ограничений на стороне сервера ресурсов). По сути если написать таким образом вредоносную программу, то можно после получения токен слить или удалить всю информацию пользователя. Имея данный токен. Мы можем использовать его в нескольких целях : использую как подтверждение того, что пользователь прошел авторизацию и теперь давать ему доступ к данным на нашем сайте (сайт с которого пользователь нажимал кнопку "Войти вконтакте") постоянно проверяя токен при доступе к приватным ресурсам на нашем сайте. То есть тот же пароль или сессия на стороне сервера (кукисы ...). Или же с помощью нашего сайта делать что-то на странице пользователя вконтакте, загружать фото, делать посты......
Теперь вопросы которые возникли у меня, кроме главного (правильно ли я вообще понимаю).
Если перехватить токен, то можно использовать его как тот же пароль. В чем тогда преимущество? Можно ограничить ресурсы разными токенами? Он временный и через некоторое время уже будет недействительным, но если злоумышленник успеет сделать что-то раньше ? То есть передавать токен как и пароль нужно в пост запросе по HTTPS протоколу, чтобы защищать его как тот же пароль? Если я использую токен от Вконтакте как авторизацию на своем сайте, то каким образом поучать новый токен по истечению срока действия старого, заново запрашивать " Вы разрешаете приложению .... " через oauth сервер. Такого не встречал на сайтах, обычно один раз разрешил и все. Данные способ авторизации удобен когда у пользователя есть какой-то глобальный аккаунт на доверенном сервере.Если же нужна авторизация на своем сервере только и без сторонних oauth серверов, следует использовать похожий принцип просто, при первой авторизации один раз передавать логин и пароль по HTTPS и получать токен уже непосредственно у сервера. Допустим интернет магазин и клиент Android.Первый раз логин и пароль, в ответ прилетает токен и доступ к API производить уже передавая этот токен. Регистрация приложения является дополнительным уровнем безопасности, то есть чтобы не все могли попросить пользователя разрешить им доступ и получить токен. Если приложение допускает авторизацию, как прямо на самом сервер (интернет магазин) так и через OAuth (вконтакте), то кто должен контроллировать время жизни токена во втором случае. В первом случае мы работаем непосредственно с нашими сервером(интернет магазин), а во втором случае мы передаем и используем токен полученный от внешнего сервера OAuth (vkontakte) каким образом нам нужно обновлять токен, просить об этом у oauth.vk.com или нам в данном Вконтакте больше не нужен, после выдачи первого токена и теперь сами на стороне сервера интернет магазина генеируем новые токены ?
Всем спасибо, кто дочитал это.
Скажите, правильно ли я вообще понимаю принцип работы? Если нет, то скажите пожалуйста где и что не так.
Спасибо всем огромное
Ответ
В принципе правильно, хоть и запутанно немного описываете. Там всё проще )
По остальным вопросам:
Нет, не так-же. Разница в правах. Для авторизации обычно не требуют прав больших чем "возможность получить имя и фамилию пользователя". В диалоге аутентификации приложения пользователь видит все права, которые оно у него требует, и если не согласен, то может отказаться. Ну и на уровне API обычно не предусматривают никаких критичных действий. Скажем, пароль или e-mail пользователя по access-токену практически нигде нельзя поменять. Да, очень желательно. Ну и большинство сервисов вообще не позволяют работать через незашифрованное соединение. Впрочем, в случае explict-авторизации, кроме как между сервисом и вашим сервером access-токен никуда не передается. Т.е. при использовании незашифрованного соединения, перехватить токен может может только ваш хостер, либо провайдер вашего хостера. Что впрочем, тоже потенциально может быть неприятным. Делают обычно по другому - через запрос нового access-токена, используя статичный refresh-токен и старый access-токен. Пользователь при этом ничего не видит, но access-токены постоянно заменяются на новые. У кого-то это происходит раз в день, а у кого-то раз в пару часов. Скомпрометированные токены при этом естественно становятся недействительными. В случае получения запроса с некорректной комбинацией refresh-токена и access-токена, сервис автоматически должен сделать оба токена недействительными, ну и соответственно в этом случае пользователь увидит окошко аутентификации приложения заново. Но это если сервис вообще выдает refresh-токены. К сожалению они опциональны, и ВКонтакте не выдает их, в отличии от Google и Facebook. В этом случае можно только периодически запрашивать что-то доступное вашему приложению. После истечения срока токена, сервис будет выдавать в ответ ошибку 400 с error=invalid_grant - в этом случае приложение должно снова перекинуть пользователя на форму аутентификации приложения на сервисе, дабы получить новый access-токен. Да, так. Так многие и делают. По похожему принципу, кстати, работает авторизация на большинстве сайтов ещё со времен создания интернета. Логин-пароль передаются сервису только один раз, возвращается некий токен(например хеш чего-либо), он сохраняется в некое хранилище(например в cookies), ну и собственно этот токен используется используется для авторизации в последующие разы. Пресловутые же email и пароль по такому токену менять не позволяют. Не только. Основная цель регистрации приложений - дать возможность администрации отключить всё приложение разработчика в связи с выполнением приложением каких-то вредоносных действий, или в случае массовой компрометации access-токенов пользователей этого приложения. Нет, не на самом сервере приложения. Сервер приложения просто отправляет сервису запрос на refresh, и в ответ получает новый access-token.
