Шаг 4 авторизации

[hram]

После получения authorization_code необходимо получить access_token.
Для получения access_token необходимо выполнить шаг авторизации 4.
Вопросы:

1. Является ли шаг 4 обязательным
2. Что означает сервер-сервер запрос
3. Как хранить параметр client_secret в приложении (например для Android) чтобы к нему нельзя было получить доступ. Если хранить client_secret в приложении то смысла нет в такой авторизации.

[maxim-yudin]

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

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

[hram]

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

[maxim-yudin]

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

[hram]

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

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

[maxim-yudin]

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

[hram]

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

[mikesub]

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 Там подробно, хоть местами и сложновато, описаны все аспекты авторизации, в том числе моменты, связанные с безопасностью.

[maxim-yudin]

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

[hram]

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

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

[maxim-yudin]

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

[hram]

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

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

[hram]

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

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

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

[mikesub]

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

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

[hram]

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

[mikesub]

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

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

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

[hram]

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

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

[maxim-yudin]

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

[maxim-yudin]

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

[hram]

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

[maxim-yudin]

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