Токены одноразового входа для стороннего доступа к ресурсу

Question

У нас есть веб-сайт (foo.com), который проводит онлайн-обучение. Пользователь входит в систему, затем завершает обучение.

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

Вот мой первоначальный план атаки:

1. Когда пользователь входит на bar.com (веб-сайт другой компании), его бэкэнд отправляет безопасный HTTPS-запрос на foo.com (наш веб-сайт), запрашивая токен одноразового доступа специально для этого пользователя. Например, они могут запросить следующий URL:

   https://foo.com/api/request_token.php?user=bob&pass=A1B2C3D4E5F6

   Это запрашивает доступ к учетной записи Боба. Компонент pass является общим паролем, известным foo.com и bar.com, который используется для проверки правильности запроса.

2. foo.com ответит одноразовым токеном доступа (например, 0123456789ABCDEFG), который сохраняется в базе данных вместе с идентификатором пользователя (bob).

3. bar.com предоставит пользователю гиперссылку, которая ссылается на онлайн-обучение на foo.com. Примерно так:

   https://foo.com/api/login.php?user=bob&token=0123456789ABCDEFG

4. Когда пользователь нажимает на ссылку, foo.com проверяет токен в базе данных и (если срок его действия не истек) удаляет его из таблицы допустимых токенов и создает переменную сеанса, указывающую, что bob теперь зарегистрирован в, затем перенаправляет его на тренировку.

Я хотел бы знать, где дыры в безопасности и как их можно устранить? Я знаю, что URL-адрес будет зашифрован, и я знаю, что запись появится в моем журнал сервера, но это одноразовый токен, так что я не беспокоюсь об этом. Я могу себе представить, что кто-то перебирает разные токены, поэтому я включил имя пользователя во второй URL-адрес входа, по которому пользователь щелкает, чтобы токен работал только с этой конкретной учетной записью.

Но что меня действительно беспокоит, так это то, чего я не знаю. И я не очень разбираюсь в вопросах безопасности здесь.

(Обратите внимание, что это касается только существующего пользователя, который пытается войти в систему. Я буду использовать другой метод для фактического создания учетной записи пользователя на foo.com)

Я пишу в PHP.

Answer 1

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

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

Существует множество реализаций / ссылок SAML для многих платформ, включая PHP. Если вы хотите сделать это правильно и безопасно, это то, что вы должны расследовать и преследовать.