Понимание использования идентификатора пользователя в трехстороннем сеансе OAuth?

Question

Сегодня, после настоящей тренировки, я чувствую, что довольно хорошо понимаю трехстороннюю аутентификацию OAuth. Что я до сих пор не понимаю, так это использование идентификатора пользователя. Все примеры, которые я видел до сих пор, кажутся просто произвольным назначением идентификатора пользователя в верхней части примера сценария и переходом. Это смущает меня.

Большая часть примера кода, который я видел, кажется, сосредоточена вокруг концепции использования идентификатора пользователя и потребительского ключа OAuth-сервера для управления «сеансом» OAuth (в кавычках, потому что я не пытаюсь связать термин с браузер "сеанс"). Например, пример кода базы данных, который я видел, хранит и извлекает токены и другую информацию, связанную с этим, на основе значений полей идентификатора пользователя и ключа потребителя.

Я сейчас нахожусь в состоянии неопределенности, когда несколько конкурирующих фрагментов понимания конкурируют и конфликтуют:

1) Если мое понимание записи сведений о сеансе OAuth или поисков «Хранилище OAuth» правильное, с помощью полей ключа потребителя и идентификатора пользователя, то не требует ли я, чтобы у меня был разрозненный идентификатор пользователя для каждого пользователя, использующего мой приложение, которое соединяется с сервером OAuth?

2) Если # 1 правильно, то как мне избежать создания собственных учетных записей для разных пользователей, чего я пытаюсь избежать? Я пытаюсь написать программное обеспечение, которое выступает в качестве внешнего интерфейса для службы с поддержкой OAuth, поэтому мне не нужно иметь свои собственные пользовательские записи и сопутствующие трудности обслуживания. Вместо этого я просто позволю серверу OAuth справиться с этим концом головоломки. Однако, похоже, из этого следует, что недостатком моего подхода было бы то, что мне пришлось бы повторно авторизовывать пользователя каждый сеанс, так как без моей собственной постоянной учетной записи / идентификатора пользователя я не мог бы искать ранее предоставленный токен доступа «хорошо отозвано», исправить?

3) Что меня беспокоит, так это то, что я читал о некоторых серверах OAuth, которые не позволяют передавать динамически указанный URL-адрес обратного вызова во время запроса неавторизованного токена, что делает невозможным передачу ключа потребителя и идентификатора пользователя обратно себе , Вместо этого вы указываете URL-адрес обратного вызова при регистрации в качестве разработчика / потребителя и все. К счастью, сервер OAuth, с которым я имею дело, разрешает эту функцию, но, тем не менее, если бы я имел дело с тем, который не имел, разве это не бросило бы гигантский гаечный ключ во всю идею использования пары ключ пользователя и идентификатор пользователя? проиндексировать детали сеанса OAuth?

Answer 1

Это ответ на вопрос Лоде :

Правильно ли, что не только у провайдера должны быть идентификаторы пользователя (это звучит логично), но и у клиента? Таким образом, клиент (использующий OAuth в качестве системы входа в систему) должен создать пользователя (с идентификатором) перед успешной аутентификацией его через сервер OAuth. Создание у вас много пустых учетных записей пользователей, когда аутентификация не проходит или доступ не предоставляется.

Можно использовать OAuth для аутентификации пользователей, не имея локальных учетных записей в потребительском приложении, но у вас должен быть какой-то механизм сеанса (куки / получить параметры), чтобы иметь некоторое внутреннее представление сеанса, в котором вы будет хранить oauth_token.

Например, если кто-то подключился к вашему веб-приложению, а ваше приложение является потребителем какого-либо поставщика OAuth, вам придется создать локальный сеанс на вашем сайте для конечного пользователя: например, с помощью файла cookie. Затем вы отправляете конечного пользователя поставщику OAuth для авторизации токена, чтобы ваше приложение могло получить защищенные ресурсы от поставщика. В настоящее время вы ничего не знаете о пользователе и не заботитесь о его личности. Вы просто хотите использовать некоторую защищенную информацию от поставщика.

Когда пользователь возвращается из провайдера после успешной авторизации и возвращает oauth_token, теперь вы должны сохранить этот токен в сеансе, который вы ранее создали для пользователя. Пока вы сохраняете сеанс (и токен, если он необходим для дальнейших запросов ресурсов), вы можете считать, что конечный пользователь вошел в систему. В тот момент, когда вы удаляете его сеанс или токен истекает, вы можете считать его больше не вошли в систему. Таким образом, вам не нужно создавать свою собственную пользовательскую таблицу БД или механизм хранения.

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

Что касается разницы между openid и oauth - с точки зрения локальных учетных записей разницы нет. Все то же самое. Разница лишь в том, что с openid вы сразу получаете некоторую базовую информацию о пользователе (электронная почта и т. Д.), А с помощью oauth вы получаете токен и вам нужно сделать еще один запрос для получения базовой информации о пользователе (электронная почта и т. Д.)

Однако нет никакой разницы в отношении локальных учетных записей, если вы собираетесь использовать OpenID или OAuth.

Answer 2

Я постараюсь высказать свое мнение по затронутым вами вопросам и надеюсь, что это немного прояснит ситуацию ...

Во-первых, идея заключается в том, что сервер OAuth защищает некоторые API или ДАННЫЕ, к которым сторонние приложения (потребители) хотят получить доступ.

Если у вас нет учетных записей пользователей или данных в вашем API за OAuth-сервером, то почему потребительское приложение захочет использовать ваш сервис - что оно получит от вас? При этом я не могу представить сценарий, в котором у вас есть сервер OAuth, а за ним нет учетных записей пользователей.

Если вы просто хотите использовать OAuth для входа в систему пользователей без предоставления пользовательских данных через API, то лучше использовать OpenID, но опять же вам придется иметь учетные записи пользователей на вашей стороне.

Ваша точка зрения верна: вы выполняете поиск по ключу потребителя и (вашему) идентификатору пользователя, и это из-за структуры протокола.

Общий поток:

1. OAuth-сервер (поставщик) выдает несанкционированный токен-запрос клиентскому приложению
2. Потребитель отправляет конечному пользователю авторизовать токен запроса на сервере OAuth (поставщик)
3. После того, как конечный пользователь авторизует токен, токен доступа выдается и передается потребителю (здесь я пропустил некоторые детали и шаги, поскольку они не важны для того, что я хочу сказать, например, потребитель получает действительный доступ). токен в конце)
4. На этапе авторизации именно ваш сервер OAuth создает и сохраняет в виде пары - какой локальный пользователь (локальный для провайдера) авторизовал какого потребителя (пара идентификаторов ключ-пользователь-потребитель).
5. После этого, когда пользовательское приложение хочет получить доступ к DATA или API конечного пользователя из провайдера, оно просто отправляет токен доступа, но не вводит данные пользователя.
6. Затем сервер OAuth (поставщик) может проверить с помощью токена, который является локальным идентификатором пользователя, который до этого авторизовал этот токен, чтобы вернуть пользовательские данные или функциональные возможности API для этого пользователя потребителю.

Я не думаю, что вы можете обойтись без местных пользователей, если вы провайдер.

Что касается вопроса обратного вызова, я думаю, что нет разницы, если у вас есть динамический или статический (при регистрации) URL обратного вызова в отношении того, как вы обрабатываете сеансы OAuth с ключами потребителя и идентификатором пользователя. Сама спецификация OAuth вообще не обязывает иметь URL-адрес обратного вызова - это необязательный параметр, который необходимо иметь, необязательный для отправки каждый раз или необязательный, чтобы зарегистрировать его только один раз в начале. Поставщики OAuth решают, какой вариант лучше использовать, и поэтому существуют разные реализации.

Когда у провайдера есть статический определенный URL-адрес обратного вызова в базе данных, связанный с потребителем, это считается более безопасным подходом, поскольку конечный пользователь не может быть перенаправлен на «ложный» URL-адрес обратного вызова.

Например, если злой человек крадет потребительский ключ GreatApp, он может сделать себя потребительским EvilApp, который может выдать себя за оригинальное GreatApp и отправлять запросы на сервер OAuth, как это было с оригиналом. Однако, если сервер OAuth разрешает только статический (предопределенный) URL-адрес обратного вызова, запросы EvilApp всегда заканчиваются URL-адресом обратного вызова GreatApp, и EvilApp не сможет получить токен доступа.