Как связаны OAuth 2.0 и авторизация в рамках одного приложения?
Есть OAuth 2.0 - это протокол авторизации между клиентским приложением и сервером с ресурсами к которому мы хотим получить доступ от лица пользователя.
Работает это добро благодаря access и refresh токенам, один для самого доступа, второй для обновления первого.
А как быть если приложение обычный клиент-сервер - с отделенным бэкендом и фронтендом. Ну то есть пользователь точно так же в форме вводит логин и пароль, отправляет его на сервер, там мы считываем проверяем хэш пароля и логин с тем что лежит в БД и если всё хорошо, генерируем JWT-токен, засовываем его в куки и всё работает. Принцип же такой же как в спецификации OAuth 2.0.
В чём отличие между таким подходом и OAuth 2.0.
Есть OAuth 2.0 - это протокол авторизации между клиентским приложением и сервером с ресурсами к которому мы хотим получить доступ от лица пользователя.
Работает это добро благодаря access и refresh токенам, один для самого доступа, второй для обновления первого.
А как быть если приложение обычный клиент-сервер - с отделенным бэкендом и фронтендом.
Есть OAuth 2.0 - это протокол авторизации между клиентским приложением и сервером с ресурсами
Нет, не так. В OAuth2 участвуют минимум 3 стороны - ресурсный сервер, клиент и сервер авторизации. Обычно OAuth используется в ситуациях когда имеется несколько ресурсных серверов и надо иметь единую точку авторизации. В этой схеме логины/пароли/рефреш-токены видит только сервер авторизации, клиент использует рефреш-токены для получения короткоживущих аксесс токенов с нужными скопами к ресурсным серверам. Компрометация одного из ресурсных серверов при правильной организации доступа не скомпрометирует доступ клиента к другим ресурсным серверам.
Средний
Сложный
