to post messages and comments.

Есть три сервиса, работающих по OAuth 2.0. Service#0 — там основные данные пользователя. Сайт — это "морда" к Service#1, куда пользователь штатным образом с редиректами логинится через Service#0. Задача — подключить Service#2 к Service#1 (не к сайту, а именно к серверу), так чтобы Service#2 поимел ключ доступа к данным Service#0 для того же ресурса, что и Service#1. Другими словами — #1 хочет залогиниться на #2 через #0, подтвердив, что он и есть тот пользователь. Не могу понять flow, которым это кошерно организовать через OAuth.

Мое предположение костыльное. #1 получает токен для доступа у #0 путем стандартного Authorization Code Grant через сайт. Затем, когда надо, #1 сам регистрируется на #2 с client_credentials. И получает как бы ключ сессии. Потом просит у #0 некий код для #2 подтвердив себя своим же токеном, который у него уже есть. #1 отдаёт полученный код в #2, #2 получает у #0 по коду токен и записывает, что считать эту сессию с #1 аутентифицированной как вот тот пользователь, что он захватил у #0.

Но я вот сомневаюсь по поводу пункта "просит у #0 некий код для #2 подтвердив себя своим же токеном". Может есть стандартная последовательсность действий? scontent.xx.fbcdn.net

Что-то не соображу. Вот есть OAuth-API. Вот у меня есть мобильный клиент для него на планшете и на телефоне. Как теория говорит их различать? client_id зарегистрирован конечно же один

Скажите мне пожалуйста. Когда сервер выдает приложению токен, этот токен привязывается к client_id приложения или его может использовать другое приложение с другим client_id?

PS в сети искал. Пока ответа не нашёл. Подозреваю что привязка должна быть.

похоже стало получаться потихоньку с OAuth. но вот такой вопрос: вот у гугла например есть и OAuth и OpenID (плюс еще несколько таких провайдеров есть), но OpenID я еще летом сделал, стоит ли заменить теперь?
мне например openid больше нравится. потому что можно легко поменять его, по сути не такая жесткая привязка к сети, которая его выдает.

При Oauth2-аутентификации Facebook генерирует уникальный блок в ~300 символов. Среди символов маленькие/большие английские, цифры, тире и подчёркивание. Набор из 26*2+10+2=64 символов. 64^300 ~= 10^541 ~= 2^1800, что в 10^461 раз больше, чем атомов во Вселенной. Зачем?

via #2024289

Ох у яндекса и реализация oauth. По всем правилам это oauth2, вот только токен нужно передавать не в параметре access_token (как по стандарту oauth2), а в параметре oauth_token (как прописано в стандарте oauth1).

А я сижу удивляюсь почему у меня их авторизация не проходит.

Что-то я, запутался, зачем нужны эти всякие flow и несколько токенов, если все равно остается implicit flow, в котором ничего не используется.

вчера узнал, што мелкософт со своим Live ID напрямую поддерживает OAuth 2.0 и в восьмой винде родная поддержка авторизаций. Т.е. теоретически, из вин-8 можно авторизоваться на любом сайте с поддержкой oauth без всяких фейсбуков/твиттеров/етц. Привинчу к паззлам и буду искать кого-нибудь с восьмой виндой :)

Ох как я это понимаю – «The sorry state of Python OAuth providers» goo.gl В то время как на руби/рельсах я без всякого опыта разработки на них поднял за пару часов нужную мне систему, реализации провайдера oauth больше, и при этом с отличной документацией и примерами. А теперь надо сделать oauth2 на tornado, и на этом застопорился, провел отличную работу для архитектуры проекта, набросал будущий API, так что бы проект выполнялся менее опытным без проблем, а вот на куске с oauth фиг знаю что сделать, хоть сам садись и пиши костыль очередной. Для django хоть год назад появился oauth2app goo.gl и то хорошо.

Я думаю, это связано с недавним обновлением OAuth у Twitter, и тем не менее занятно выглядит:
Неожиданная ошибка $1 при обновлении твита. Попробовать снова.Они хотят один бакс за обновление твита!!! -_-

как выяснилось, ничего приличного для написания даже самого примитивного OAuth2 сервера для Python пока не написано, есть заброшенная python-oauth и ее форк python-oauth2. увы цифра в названии означает версию протокола :(

Читаю про OAuth, вспоминаю, как когда-то мучался с глюками OpenID: всякими мелкими отличиями в реализации у разных провайдеров. И что-то не представляю, как использовать OAuth в не-web приложениях, чтобы это было удобно для пользователя.
Кстати, OpenID оказался нафиг никому не нужен, все используют Facebook Connect. :)

А вы знаете, что с введением новой фичи #634775 можно написать своего жуйкобота с шахматами и поэтессами? Можно и подписку на теги устроить и свой синтаксис комманд прикрутить, при этом работать вы будете с одним ботом. Чисто для себя это можно было и раньше сделать, но теперь такого бота можно сделать доступным массам. Для желающих заводим уникальный jid на домене сервиса, предлагаем юзера добавить его в свой аккаунт и спрашиваем у юзера код авторизации. Всё! Дальнейшую работу с джуйком юзер может вести через тот самый jid: постить сообщения, подписываться на теги, получать ответы в любом виде и тд. Для полного счастья хотелось бы чтобы это было реализовано через oAuth, дабы юзеру оставалось только нажать кноку разрешить доступ сервису, но и это уже хорошо.