Делаем интеграцию Одноклассников в наше приложение (андроид и сайт, они работают через наш сервер). У нас есть свой профиль пользователя, однокласснкии используем как способ авторизации и берем некоторые данные для заполнения профиля при регистрации. Клиенты (андроид и сайт), по умолчанию не надежны, следовательно авотризация также проверяется и на нашем сервере. Собственно вопрос, как валидировать/верифицировать токен полученный от апи одноклассников? Например, вконтакте есть метод checkToken, в фейсбуке debug_token, в Гугл+ tokeninfo, все эти методы возвращают информацию о токене и его валидности, которые проверяются на нашем сервере. Эти методы работают по протоколу сервер-сервер, то есть нет редиректа на разрешение приложения. Есть ли подобное апи в одноклассниках? Возможно, мы просто проглядели. Заранее благодарны.
В принципе, можно, спасибо, но вообще очень странно, что сервер будет использовать клиентскую сессию, а не свою собственную, и чтобы проверить валидность токена, нам нужно дергать клиентский запрос (который, кстати, по этому токену и работает) с кучей не нужной в данной задаче информации, также не понятно почему у вас нет сервисных (технических) апи, а только клиентские, например, в этой задаче нам не нужны все эти данные (информация о пользователе), которые возвращает запрос users.getCurrentUser, а требуются сугубо технические, например, валиден ли токен/сессия, сколько он действителен, userId пользователя, идентификатор приложения для этого токена/сессии. Также интересен момент, если при формировании application_key подставить application_secret_key из другого приложения, не привязанного к проверяемому access_token, будет ли ошибка?
Валидность сессии подтверждается успешным вызовом, из ответа получаем id пользователя сессии.
Получение экспирации сессии вещь ненадежная - с одной стороны есть пермиссии которые позволяют делать автопродлеваемые сессии, которые могут жить годами, с другой - пользователь может в любой момент запретить приложению далее работать под его именем.
app_secret_key в запросе участвовать не будет - куда вы планируете его передавать? есть запросы сессионные (клиентские, подписываются сессионным ключем) и несессионные (в том числе серверные, подписанные ключем приложения). В данном случае вы передаете сессию, поэтому подписываете запрос секретным ключем сессии'
Ну никто и не заставляет делать автопродлеваемые сессии, которые дляться годами, для клиентов, их можно использовать для апи типа сервер-сервер. Насчет экспирации, то для этого и существуют сервисные запросы типа checkToken, чтобы проверить разрешения приложения и т.д.
Да, прошу прощения, в последнем вопросе имелось ввиду поле application_key из примера вашей доки, https://api.ok.ru/fb.do?application_key=CBAPFHGLEB... Проблема в том, что запрос users.getCurrentUser сессионный, и нашему серверу, чтобы с ним работать, надо пользоваться сессией клиента (например, пользователя приложения), что, согласитесь, не есть хорошо, а получить свою ссесию сервер не может, потому что ваши апи клиентские, и ориентированы на подтверждение пользователем разрешения на приложение (redirect_uri), чего REST-сервис сделать не может.
Ну в настройках приложения можно получить вечный токен для вашего пользователя, которым вы можете пользоваться для вызова сессионных методов. Только сессия будет ваша и пользователь там будете вы)
Вообще в ОК все сессии - пользовательские, поэтому без пользователя получить серверную сессию все равно не выйдет. Так что надо либо передавать сессию на сервер и там валидировать (все равно же передаете), либо проходить не клиентский а серверный OAUTH, когда токен получаете через REST запрос, и тогда передаете клиенту сессию для использования.
Да, вы абсолютно правы, так и поступаем за неимением ничего другого, но, подскажите, в будущем вы рассматриваете возможность не пользовательских сессий (как мы ранее писали, сервисных или технических), чтобы можно было получить токен программным путем без подтверждения разрешения на приложения, без создания каких-либо пользователей, а просто имея идентификатор и секретный ключ приложения? Это было бы очень круто, по аналоги с другими соц. сетями.
Такая возможность есть
Есть методы которые расчитаны только на пользовательскую сессию - работают от имени пользователя.
Есть методы которые расчитаны работать вне сессии пользователя.
Эти подмножества пересекаются, то есть ряд методов работают как по сессии, так и без неё (подпись ключем приложения), но метод вроде users.getCurrentUser логично что к таким не относитя. А вот, например, users.getInfo относится
Возможно, есть ряд методов которых действительно по валидным причинам должна быть возможность вызывать вне сессии - мы можем добавить такой режим.
Простой
Средний
Простой
