OAuth 2.0 для веб-служб REST

Question

Я реализую уровень REST для существующего приложения. У меня есть мой идентификатор пользователя и пароли, хранящиеся в базе данных, и я хотел бы аутентифицировать эти учетные данные при вызове моих служб REST. Обратите внимание, что это автономное приложение.

После расследования я выяснил 2 пути.

• Базовая реализация с HTTPS - такой подход гарантирует, что идентификатор пользователя и пароль передаются не подделан человеком в центре нападения.
• Использование маркера аутентификации (JWT) - пользователь сначала передает его идентификатор и пароль и сервер возвращает к пользователю Authentication token.Once есть маркер аутентификации, который может быть использован для последующего запроса.
• Использование OAuth 2.0 - Я очень смущен в этом подходе. После прочтения документации и спецификации, я обнаружил, что, поскольку мое приложение является автономным, мне нужно реализовать сервер авторизации, ресурс сервер и т.д.

Я попросил реализовать OAuth здесь, но я не уверен что OAuth требуется в этом сценарии. Я более склонен к простому внедрению JWT (токенов)

В этом сценарии действительно установлен OAuth. То, что я понимаю в OAuth, используется, когда у вас уже есть служба, например Facebook/Google.

Может ли кто-нибудь подтвердить, правильно ли мой ход мыслей, и если в этом случае требуется OAuth 2.0?

Answer 1

Основная цель OAuth 2.0 - предоставить пользователям возможность аутентификации для использования клиентского приложения через сторонний поставщик аутентификации (например, Google, Facebook и т. Д.), Не подвергая свои учетные данные (как правило, имя пользователя/пароль) клиент.

В вашем случае, если пользователи только будут проходить аутентификацию в вашей системе, используя свои учетные данные в вашей базе данных, то реализация OAuth 2.0 не добавит вам существенной ценности.

Спецификация OAuth 2.0 определяет "Resource Owner Password Credentials grant", предназначенный для устаревших прецедентов, которые применимы к вашей ситуации: пользователь отправляет учетные данные, и вы возвращаете токен доступа (это может быть JWT, если хотите). Если это желательно с точки зрения управления или маркетинга, вы можете реализовать грант Credentials владельца ресурса и законно заявить, что ваше приложение «соответствует подмножеству OAuth2, как определено RFC6749».