Оценка состояния входа в систему для каждого запроса при аутентификации с использованием OpenID, OAuth и / или OAuth 2.0

Question

Я нахожусь в процессе создания расширенной области входа в систему / регистрации для моего веб-сайта, которая включает параметры входа OpenID, OAuth (Twitter) и OAuth 2.0 (Facebook).

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

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

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

Это один из тех сценариев "это действительно не имеет значения", или я неправильно все рассматриваю?

Answer 1

Определенно, поставщики услуг не хотят, чтобы вы пинговали их услуги для каждого запроса, поступающего в вашу службу. Даже Google отказывается от мысли о , что . Вы можете установить какой-то тайм-аут для проверки каждые 5 минут, но я думаю, что ваша идея сессионного куки является идеальной. Но да, это зависит от того, чего вы пытаетесь достичь.

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

Если вы хотите получить доступ к данным пользователя на этих сервисах, тогда, конечно, держите маркер доступа рядом. Но вам все еще, вероятно, следует придерживаться собственной концепции входа пользователя в систему. Если я правильно помню, эти маркеры доступа обычно являются долгоживущими (в любом случае в OAuth 1.0a), и они не помогут вам, когда пользователь вернется, чтобы определить, пользователь - это тот, кем они себя называют, если только у вас нет собственного cookie-файла или вы снова отправляете его через службу входа в систему.

Answer 2

Если вы просто используете OAuth / OpenId для входа в систему, я не думаю, что вам следует беспокоиться об этом.Вы должны беспокоиться, если ваши пользователи - это те, кого они называют их (поставщик OAuth / OpenId).

Если ваш сайт намеревается взаимодействоватьТвиттер и Фейсбук, это другое дело, но все же это в значительной степени решается само собой.Когда вы пытаетесь взаимодействовать с FB, когда ваш пользователь вышел из системы, FB предложит вашему пользователю войти снова.

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