Шаг 4 авторизации about api HOT 20 CLOSED

1. Конечно является как же вы без него получите access_token.

сервер-сервер имеется ввиду что надо отправить POST-запрос на адрес http://m.hh.ru/oauth/token с параметрами
grant_type=authorization_code&client_id=...&client_secret=...&code=...

from api.

Странно ) Я под сервер-сервер понимаю совсем другое:
сервер-сервер взаимодействие между двумя серверами;
клиент-сервер между клиентом и сервером;
клиен-клиет между клиентами.
Это я просто придираюсь к документации
Интересен пункт 3 моего вопроса.

from api.

Я тоже )) Может я не правильно понял доки

from api.

Недавно написал приложение для ВКонтакте. Там тоже используется OAuth 2.0 авторизация. Есть у них и client_secret называется "Защищенный ключ" только в программе я его не использовал и в приложении не храню. Программа работает на ура.

Защищенный ключ у них используется как я понял для серверного взаимодействия сервер-сервер как говорится ) Тоесть если у тебя есть приложение на Android например и еще есть серверная часть. Вот серверная часть общается с API ВКонтакте через Защищенный ключ

from api.

а для чего он у них используется этот Защищенный ключ

from api.

Я исправил сообщение выше, извиняюсь сразу не написал. Это как я понял.

from api.

1. Да, сейчас у нас реализован способ авторизации при помощи authorization code. В OAuth2 есть еще один способ ( implicit grant ), когда access_token выдаётся сразу на запрос. Это менее безопасно. Такой вариант используется для client-side приложений, когда нет возможности сделать фоном сервер-сервер запрос.
2. В данном случае клиент - это пользователь и его User-Agent (браузер), а два сервера - это сервер авторизации ( m.hh.ru ) и нативное приложение. "Cервер-сервер" означает, что запрос делается не при помощи пользовательского User-Agent, а фоном без участия пользователя и тем самым client_secret не светится.

Советую ознакомиться с документацией по OAuth2: http://tools.ietf.org/html/rfc6749 Там подробно, хоть местами и сложновато, описаны все аспекты авторизации, в том числе моменты, связанные с безопасностью.

from api.

Я думаю @hram имел ввиду, что client_secret надо хранить внутри приложения, например в виде константы, и при декомпиляции злоумышленник может его получить.

from api.

@maxim-yudin, спасибо именно это я и имел ввиду. Получается, что для разработки приложения для iOS-Android-<другой мобильной платформы> необходимо поднимать сервер, покупать домен, платить ежегодно за хостинг ради получения списка вакансий которые и так доступны.

P.S. ответ на 3 вопрос очень хочется услышать )
P.P.S чето я в троли записался, поймите меня правильно, я застрял на этом, думаю и другие застрянут если такие будут

from api.

@hram для чего? вам же написали спокойно получаете по методу, описанному в доке. если так боитесь за сохранность - храните его в зашифрованном виде.

from api.

@maxim-yudin какая разница как его хранить. если он хранится на клиентской стороне то он уже не секретный ключ. Если дешифровать алгоритмом реализованным на клиентской стороне то нет проблем посмотреть этот алгоритм, иначе надо поднимать сервер для дешифрации ключа на сервере.

@mikesub спасибо за RTFM. Читать я умею.

from api.

@mikesub Почитал мануал и другие статьи. Вот вам ссылочка на замечательную статью на habrahabr. Почитайте главу Авторизация полностью клиентских приложений

Этот вариант требует поднятия в приложении окна браузера, но не требует серверной части и дополнительного вызова сервер-сервер для обмена authorization code на access token.

Все примеры на родном вам mail.ru

from api.

@hram я как раз об этом вам писал, когда упомянул implicit grant. Но в этом случае еще легче злоумышленнику: не надо обладать client secret, достаточно знать client id (который доступен в открытом виде) и перехватить ответ с access token.

Любая информация хранящаяся в телефоне доступна тому, у кого этот телефон. Никакого решения для этого нет. Нельзя сделать абсолютно безопасным, можно только усложнить жизнь злоумышленникам.

from api.

@mikesub в моем случае доступны и client_id и client_secret, для меня они равны (лежат в общедоступном месте), а значит шаг 4 авторизации излишен. Но я мог бы если уж очень хочется (не ваш вариант) часть API связанную например с платежными транзакциями защитить и вынести на сервер. В вашем случае это не реально так как client_secret лежит у клиентов.

from api.

@hram дополнительный промежуточный шаг с обменом authorization code на access token не излишен, он повышает безопасность (но не обеспечивают полностью), так как чтобы получить client secret необходимо покопаться в исходниках приложения. Не очень корректно обобщать client_id публично передаваемый в URL и client_secret, который используется в фоновом запросе.

Если вам необходима повышенная степень безопасности, вы можете направлять полученный от клиента временный authorization code на удаленный сервер, там производить обмен его на access token и возвращать в приложение уже access token. Но это overkill какой-то.

Вариант с implicit grant мы реализуем, но первым этапом мы выпустили более безопасный метод.

from api.

Поясню почему еще я так уперся. После того как в окне браузера пользователь согласился и нажал "ОК" в программу через редирект передается authorization_code. Если бы передавался сразу access_token было бы замечательно. А так придется поднимать поток/асинхронный таск, чтобы сделать еще один бессмысленный(для меня) в плане защиты запрос. На котором можно отвалиться/словить ошибку и заставлять пользователя ждать.

В исходниках java приложения копаться вообще нет проблем. Перечитал не мало декомпилированных программ. Только комментариев нет. А если сделать на PhoneGap то и с комментариями )))

from api.

У меня знакомый, который делает под Android Twiiter-клиент делает именно так "Если вам необходима повышенная степень безопасности, вы можете направлять полученный от клиента временный authorization code на удаленный сервер, там производить обмен его на access token и возвращать в приложение уже access token. Но это overkill какой-то."

from api.

@hram только тут вопрос вот еще в чем, кому может ваша программа понадобится :) логин и пароль пользователь все равно вводит на сайте hh.

from api.

@maxim-yudin я выше пояснил почему я "уперся" )

from api.

@hram вам уже объяснили что шаг не лишний, у вас есть только браузер могут перехватить это дело например, а так вы в приложении фоном минуя браузер посылаете еще один допзапрос, что повышает безопасность, хоть и не намного. Также @mikesub упомянул, что все-таки телефон приватный и именно в данном случае безопасность не так критична. Вы же сами не будете ломать свою программу.

from api.