OAuth2 для REST API с тесно связанным SPA в качестве единственного клиента

Question

Я разрабатываю REST API с тесно связанным SPA в качестве единственного клиента упомянутого REST API.

Допустим, SPA доступен по myservice.com, а api ниже myservice.com/api. В основном это один сервис, просто разделенный на уровне кода и развернутый по разным корневым путям.

Сейчас я использую для безопасности OAuth2 с типом предоставления ROPC (имя пользователя / пароль).

Здесь возникает проблема. Я постоянно читаю, что ROPC небезопасен и не должен использоваться. Что я должен использовать тогда?

Мой REST API действует как сервер авторизации, но сам по себе не имеет веб-интерфейса. Так что любой поток, включающий перенаправление, на самом деле не имеет смысла. SPA и API настолько тесно связаны, что для конечного пользователя это одно приложение. Там нет третьей стороны.

Я мог бы добавить простую форму входа в API, доступную, скажем, myservice.com/login. Но я изо всех сил пытаюсь увидеть разницу, которая изменится.

Безопасность в этом приложении очень важна.

Вот мои вопросы:

Действительно ли использование ROPC действительно опасно в этом сценарии?

Каким будет идеальный способ аутентификации и авторизации?

Или, может быть, OAuth2 полностью избыточен без посторонних?

Используемые технологии:

Сервер: Spring Boot

Answer 1

Является ли использование ROPC действительно опасным в этом сценарии?

Нет, не предоставляя:

a) Вы не храните пароль пользователя - возможно, используйте толькочтобы получить начальный доступ и обновить токен - хотя это может быть сложно с SPA.

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

Каким будет идеальный способ аутентификации и авторизации?

Это зависит от многих вещей.Недостаточно информации, чтобы попытаться ответить на этот вопрос.OAuth2.0 (с, вероятно, внедренным сервером авторизации) является довольно хорошим способом для примера, который вы здесь видите.

Или, может быть, OAuth2 полностью избыточен без стороннего поставщика?

Если другие приложения будут вовремя использовать ваш API, то OAuth2.0, вероятно, является хорошим вызовом.В противном случае вы могли бы использовать более простое решение, например, сеансовые куки, поскольку все они находятся в одном домене.

Answer 2

Ответ на этот вопрос можно получить из спецификации OAuth 2.0 (RFC6749) .Он определяет, когда грант ROPC подходит для

4.3.Предоставление учетных данных пароля владельца ресурса

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

Согласно вашему объяснению, у вас есть тесная связь с SPA и бэкэндом.Также у вас есть как сервер авторизации, так и сервер ресурсов.Это полностью приемлемая реализация .

Сервер авторизации может быть тем же сервером, что и сервер ресурсов , или отдельным объектом.

Так что теперь важно выяснить, почему вы используете OAuth 2.0 в вашем сценарии.

Если вы используете OAuth 2.0 для получения токенов, сохраняйте их, как определено спецификацией OAuth 2.0, тогда это совершенно непросто.,Но если вы делаете это, чтобы следовать тренду, подумайте дважды.

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

Например, тот же сервер авторизации может использоваться для выдачи токена для будущих интеграций / вторичного приложения.IMO, использование OAuth 2.0 упрощает интеграцию, поскольку оно определяет протокол для выдачи токенов, их обновления и отзыва.! Но в таком сценарии интеграции может потребоваться использование другого гранта.Тем не менее, если ваш API авторизован на токене, вам нужно только беспокоиться о том, как новая интеграция / приложение получают токены.Это лучше, чем использовать сеансы с проверкой подлинности

Возвращаясь к вашим вопросам,

В: Действительно ли использование ROPC действительно опасно в этом сценарии?

Как объяснено, если между клиентом и сервером авторизации существуют корректные доверительные отношения, то это нормально.Но помните о сложности, если у вас есть сервер авторизации .

В: Каким был бы идеальный способ аутентификации и авторизации?

OAuth2.0 для авторизации .Вы получаете токены доступа и используете их для авторизации против ваших защищенных API.С помощью API вы делаете проверку токена, чтобы определить правильные уровни доступа / разрешения.

Если вы хотите аутентификацию , то вы должны использовать OpenID Connect .Это протокол, расширенный с OAuth 2.0.И позволяет вашему приложению аутентифицировать конечного пользователя на основе идентификатора токена.Вы можете использовать грант ROPC для получения токена ID.!

В: Или, может быть, OAuth2 полностью избыточен без участия третьей стороны?

Не обязательно.Это позволяет разрабатывать ваши API-интерфейсы современным стандартным способом.Кто знает, что ждет в будущем (опять сценарий интеграции).Следование протоколу позволяет это легко.

Только советы, внимательно следуйте спецификациям.Не изобретайте свой собственный протокол / адаптацию.Это усложняет обслуживание.