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

ищу PHP-скрипт для авторизации через fb/vk/twt/еще_что-нибудь_опционально. чтобы всё в одном, и для PHP-ламеров :)

При 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 без всяких фейсбуков/твиттеров/етц. Привинчу к паззлам и буду искать кого-нибудь с восьмой виндой :)

Ахренеть: #OAuth позволяет авторизоваться мне на сайте через яндекс через твиттер через фейсбук. Одновременно/последовательно.

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

Ненавижу oauth протокол за то, что он требует наличие браузера на устройстве. Безопасности не прибавляет, а удобства разработки и свободной памяти лишает неплохо так.

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

Опа нифига ) Даже тентакль зашевелился (и о боги, ко второй таки версии решили сделать) и сделал интеграцию OAuth со своим сервисом. Поздно зачесались, но лучше, чем никогда.

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

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

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