Правильный способ использования «Войти с LinkedIn» для идентификации пользователей на моем веб-сайте?

Question

Я пытаюсь понять «Войти с LinkedIn». Кажется, я только хватаю часть картины.

Как я понимаю, пользователь подписывается с LinkedIn на моем веб-сайте, а LinkedIn возвращает уникальный идентификатор пользователя на мой сайт.

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

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

Кроме того, что должно помешать кому-либо найти чужой идентификатор пользователя, а затем использовать его для доступа к моему сайту?

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

Может кто-нибудь объяснить, пожалуйста?

Благодаря

Answer 1

Я отвечу сам. Оказывается, вы также можете попросить LinkedIn API также вернуть файл cookie, содержащий подпись. Верните этот файл cookie на ваш сервер на сервере HTTPS, и вы можете проверить подпись на свой собственный ключ API. Voila - вы доказали, что это действительный пользователь, и вы доказали, что логин пользователей действительно пришел из LinkedIn, а не подделка.

Answer 2

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

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

В принципе, вы в безопасности, если вы всегда используете API-интерфейс linkedin для аутентификации пользователей linkedin и не имеете формы на своем сайте с запросом «ввести идентификатор связанного идентификатора для аутентификации». Даже если пользователь знает идентификатор другого пользователя, им все равно нужно связать имя пользователя/пароль для API, чтобы вернуть этот идентификатор.

Не стесняйтесь хранить возвращаемый идентификатор, чтобы отслеживать пользовательские настройки/действия. Вы даже можете связать его с пользователем, уже находящимся в вашей базе данных, и предоставить пользователю возможность войти в систему с помощью комбинации имени пользователя/пароля, хранящейся в вашей базе данных (соленый/хешированный, надеюсь) ИЛИ через один из опций oauth.

Надеюсь, это поможет очистить все!

EDITED НА ОСНОВЕ КОММЕНТАРИИ

Еще один момент акцент о том, как вы обработки вещи после запроса API. Вы можете доверять тому, что идентификатор, полученный с помощью linkedin, является правильным, но после этого вы также должны быть уверены, что идентификатор, хранящийся на вашем сайте, по-прежнему остается тем же, что вы получили от linkedin. Используйте серверную часть, которую пользователь не может редактировать, чтобы сохранить этот идентификатор (например, сеансы PHP - НЕ-url-аргументы).

Answer 3

Предположим, что после того, как пользователь завершит свою идентификацию успешно,
перенаправляет на вашу страницу http://www.xyz.com/redirect.php.

Теперь у вас есть код в перенаправлении.php, который принимает параметры oauth из URL-адреса и вызывает идентификатор пользователя.

function getUserID(){ 
    // code which takes oauth params and calls linked in api with access token 
    //and returns userId of user 
    return userID; 
} 

$userID = getUserID(); 

Теперь, так как ваш есть $userID, создать сеанс с $userID и перенаправить пользователя на его/ее домашней странице. Проверьте сеанс на домашней странице, если установлен сеанс $userID, разрешите пользователю открывать страницу, если сеанс недоступен, не покажите страницу и не сообщите им сначала войти в систему.

Теперь, на ваш вопрос, как вы думаете, в этом подходе пользователь может ввести userID самостоятельно?