Ответ 1
Это хороший вопрос - есть много путаницы вокруг токенов и OAuth.
Прежде всего, когда вы упоминаете OAuth, вы, вероятно, ссылаетесь на стандарт OAuth2. Это последняя версия протокола OAuth, и это то, о чем говорит большинство людей, когда говорят "OAuth".
Протокол OAuth поддерживает несколько различных типов аутентификации и авторизации (4, если быть точным).
Во-вторых, протокол OAuth работает путем аутентификации пользователей через токены. Идея здесь такова:
Вместо того, чтобы ваш пользователь отправлял свои фактические учетные данные на ваш сервер по каждому отдельному запросу (например, с помощью Basic Auth, где пользователь отправляет свое имя пользователя/пароль на сервер для каждого запроса), с OAuth вы сначала обмениваете своего пользователя учетные данные для "токена", а затем аутентифицировать пользователей на основе этого "токена".
Идея OAuth заключается в том, что, требуя от пользователей более часто передавать свои конфиденциальные учетные данные по сети, могут быть менее плохие вещи. (Во всяком случае, это идея.)
Теперь, где вводятся токены: спецификация OAuth построена вокруг концепции жетонов, но НЕ УКАЗАНА, ЧТО ТОКЕН.
В самом "общем" смысле токен - это просто строка, которая однозначно идентифицирует пользователя. Что это.
Люди поняли это и разработали новый стандарт для создания токенов, называемый JSON Web Token standard. Этот стандарт в основном предоставляет набор правил для создания токенов очень определенным образом, что делает маркеры более полезными для вас в целом.
JWT позволяют делать такие вещи, как:
- Криптографически подписывать токен, чтобы вы знали, что токен не был подделан пользователем.
- Шифровать токены, чтобы содержимое не могло быть прочитано простым текстом.
- Вставить данные JSON INSIDE в символическую строку стандартным образом.
Теперь, по большей части: почти все в сообществе разработчиков согласны с тем, что если вы используете какой-либо OAuth, то маркеры, которые вы используете, должны быть JSON Web Tokens.
==========
OK! Теперь, когда мы рассмотрели предысторию, позвольте мне ответить на ваш вопрос.
Выбор, который вы делаете выше, заключается в том, хотите ли вы включить полную спецификацию OAuth2 для аутентификации/авторизации (что довольно сложно) или вам просто нужна базовая "токен-аутентификация".
Поскольку протокол OAuth предоставляет несколько разных способов аутентификации в режиме STANDARDS COMPLIANT, он добавляет большую сложность большинству систем аутентификации.
Из-за этого многие фреймворки предлагают "отключенную" версию потока паролей OAuth2, которая по сути является простым методом, где:
- Пользователь отправляет свое имя пользователя/пароль на ваш сервер по определенному URL-адресу, например /login.
- Ваш сервер генерирует токен JWT для пользователя.
- Сервер возвращает этот токен пользователю.
- Пользователь сохраняет этот токен в своих файлах cookie, мобильном устройстве или возможном сервере API, где они используют его для выполнения запросов.
Опять же: поток выше НЕ соответствует требованиям OAuth, но это немного более простая версия, в которой STILL использует токены.
Основной смысл здесь в том, что токены (JWT), как правило, полезны и не нуждаются в спаривании с потоком OAuth.
Я понимаю, что это стена текста, но, надеюсь, она более подробно ответит на ваш вопрос =)