Блог

Я реализовал простое приложение Angular 2, которое использует ASP.NET Основной WebAPI в качестве серверной части. Для аутентификации я добавил маршрут «/ login», который генерирует токены доступа и обновления JWT, которые, в свою очередь, хранятся SPA в localStorage и используются в HTTP-запросах.

Теперь я хочу интегрировать функцию социальной регистрации, чтобы пользователи могли входить в систему с помощью кнопки ie Facebook. С точки зрения пользователей я хочу выполнить это в 3 шага:

1. Нажмите кнопку Зарегистрироваться с помощью Facebook и перенаправлены на веб-сайт Facebook (для входа в систему и подтверждения моего запроса приложения).
2. Нажал подтвердить и перенаправлен на страницу my SPA where / registration, где его имя уже заполнено из профиля Facebook
3. Заполняет оставшиеся поля (как его любимая игрушка) и нажимает «Завершить регистрацию»

После этой регистрации, если пользователь снова нажмет кнопку зарегистрироваться через facebook, он будет перенаправлен на facebook (если он уже вошел в систему), он автоматически перенаправляется на серверный маршрут, который проверяет, был ли такой пользователь уже зарегистрирован, и, если это так, перенаправляет его на домашнюю страницу SPA

Как правильно интегрировать такой рабочий процесс в мое приложение? Примечание: я хочу выполнить аутентификацию и регистрацию внутри моего приложения Angular2, а не на другом сервере аутентификации.

Я хочу выполнить аутентификацию и регистрацию в моем приложении Angular2.

То, что вы ищете, — это неявное предоставление, с Facebook в качестве сервера авторизации и в качестве сервера ресурсов. Неявный грант поддерживает авторизацию для одностраничных приложений (таких как ваше приложение Angular2), а API Facebook Graph поддерживает запросы на информацию о пользователе.

Как правильно интегрировать такой рабочий процесс в мое приложение?

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

1. перенаправить пользователя на Facebook для входа в систему,
2. подтвердите перенаправление обратно со страницы входа в Facebook и сохраните токен доступа,
3. вызовите Graph API Facebook, чтобы запросить информацию о пользователе для связанного токена доступа, и
4. используйте эту информацию о пользователе для заполнения полей в вашем приложении.

Вызов API на третьем шаге может выглядеть примерно так:

 FB.api('/me', (user) => { 
    console.log(user.id); // 101540562372987329832845483
    console.log(user.email); // example@example.com
    console.log(user.first_name); // Bob
});
  

/me это специальная конечная точка Graph API, которая «преобразуется в user_id пользователя, токен доступа которого в настоящее время используется для выполнения вызовов API». Затем конечная точка возвращает соответствующую информацию о пользователе.

Ваше приложение может использовать эту информацию о пользователе Facebook для заполнения своих клиентских полей и / или серверной базы данных. Это id уникальный для вашего приложения и НЕ эквивалентный Facebook user_id ; id это разумный способ уникальной идентификации пользователей вашего приложения.

Четыре варианта правильной интеграции этого потока в ваше приложение.

• Вероятно, лучше всего следовать рекомендациям Facebook. Это:
• используйте их логин с помощью кнопки Facebook и / или
• используйте их логин для веб-JavaScript SDK.
• В качестве альтернативы можно использовать существующую библиотеку OAuth2, например satellizer.
• Или, если вы хотите проделать большую работу, вручную создайте свой собственный поток входа.

В сторону: что вы подразумеваете под псевдо-аутентификацией OAuth2?

OAuth2 — это схема псевдо-аутентификации, поскольку OAuth2 НЕ является протоколом аутентификации.То есть после входа пользователя в систему ваше клиентское приложение получает токен доступа, который оно использует для выполнения запроса защищенного API. Чтобы избежать подводных камней, полезно знать о них:

1. Токены доступа НЕ являются доказательством аутентификации.
2. Доступ к защищенному API НЕ является доказательством аутентификации.
3. Злоумышленники могут вводить токены доступа.
4. Токены доступа НЕ имеют ограничения аудитории.
5. Злоумышленники могут вводить неверную информацию о пользователе.
6. У каждого поставщика удостоверений может быть свой собственный протокол идентификации.

Я бы просто предложил это для auth0 A2.