Скажем, у нас есть SPA, служба OAuth (Google или FB или Linked in) и сервер приложений (наш API), который отправляет SPA клиенту.
Наш SPA аутентифицирует со стороны клиента с помощью OAuth против третьей стороны, например, google, или по ссылке, или по FB, метод, который называется «неявный поток». Который возвращает токен доступа, пройдя дополнительный шаг.
Теперь, как мы используем этот токен доступа для связи с нашим API. Они отделены.
На данный момент клиентское приложение (SPA) имеет токен и идентификатор пользователя FB | GOOGLE | LINKEDIN, которые мы получили от стороннего OAuth.
Теперь предположим, что мы делаем запрос GET к нашему серверу, и это должен быть запрос с проверкой подлинности. Как мы используем этот токен, который мы получили от OAuth
1) Делаем ли мы вызов API из SPA на наш сервер APP (наш сервер api) с тем токеном, который мы получили от OAuth, и мы снова переделываем еще один вызов службе OAuth с сервера APP на этот раз с тем же токеном и убедитесь, что это действительный токен, и создайте JWT из этого токена и используйте jwt для следующих вызовов API.
2) Или мы реализуем стандартную реализацию OAuth на стороне сервера, используя FB | GOOGLE | LINKEDIN, и после аутентификации сохраняем этот токен доступа на стороне сервера для этого пользователя и предоставляем SPA клиенту, а затем передаем этот токен доступа, полученный с сервера OAuth. клиенту. Теперь этот токен можно использовать для отслеживания вызовов API.
3) Или мы реализуем стандартную реализацию OAuth на стороне сервера, используя FB | GOOGLE | LINKEDIN, и после аутентификации мы сохраняем этот токен доступа на стороне сервера для этого пользователя и обслуживаем SPA, но на этот раз создаем JWT и предоставляем его клиенту и Теперь клиент может использовать JWT для следующих вызовов.
Я не знаю, каков правильный путь. Или, если это даже хороший способ аутентификации с использованием OAuth с SPA, так как Implicit Grant , очевидно, не является хорошим способом для этого.