Поток OAuth2 - проверяет ли сервер с сервером аутентификации?

10

Я много читал об OAuth2, пытаясь разобраться в этом, но я все еще что-то путаю.

Я понимаю, что клиент авторизуется у поставщика OAuth (например, Google) и позволяет серверу ресурсов иметь доступ к данным профиля пользователя. Затем клиент может отправить токен доступа на сервер ресурсов и получить его обратно.

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

Но это кажется огромной дырой: сервер ресурсов должен каким-то образом проверять токен доступа, в противном случае я могу просто подделать любой старый запрос и передать старый, украденный, поддельный или случайно сгенерированный токен, и он просто примет его.

Может ли кто-нибудь указать мне на простое объяснение OAuth2, потому что те, которые я прочитал, пока не полны.

security oauth2

— drekka
источник

8

Нашел это. Похоронен в спец. Говорят, что сервер ресурсов должен проверять токен доступа с сервером аутентификации, но это выходит за рамки документа. Жаль, я думал бы, что проверка токена была важной частью.

— drekka
источник

1

Что касается важных частей , возможно, стоит прочитать этот пост в блоге, чтобы узнать о приоритетах OAuth2.

— Ларс Виклунд

1

Спасибо за это, интересное чтение. Мои требования довольно просты: я хочу разрешить приложению iOS проходить аутентификацию с помощью Google, Twitter, Facebook и т. Д., Передать некоторую форму авторизации на мой сервер, а мой сервер должен проверить ее и разрешить доступ к ресурсам. Проблема оказалась более сложной, чем я ожидал, из-за сложности понимания того, как это работает и что я должен делать, где.

— drekka

Точнее, Приложение A: «Для проверки подписи на запросе защищенный ресурс мог бы передать идентификатор токена конечной точке самоанализа сервера авторизации для получения необходимой ключевой информации, необходимой для этого токена. Подробности этого использования находятся вне объем этой спецификации и будет определен в расширении [...] ".

— JulienD

2

Проверка токена обычно выполняется одним из двух способов.

1) Токен криптографически подписан с использованием предварительно общих ключей. Это имеет очевидные недостатки для использования в распределенных, разрастающихся системах.

2) Сервер авторизации (AS) предоставляет конечную точку для проверки токена или самоанализа. Этот метод был стандартизирован в IETF RFC 7662 в октябре 2015 года, см. Https://tools.ietf.org/html/rfc7662.

Этот вопрос / ответ о переполнении стека включает примеры от Google и Github: /programming/12296017/how-to-validate-an-oauth-2-0-access-token-for-a-resource-server

— Хоуи Росс
источник

0

вы читаете спецификацию для проверки токена:

https://tools.ietf.org/html/rfc7662

надеюсь, это поможет - пожалуйста, отметьте это как ответ, если он отвечает на ваш вопрос / проблему

— Чираг
источник

4

Добро пожаловать в Программирование. В своем нынешнем виде этот ответ не соответствует нашим рекомендациям по качеству . Мы ожидаем, что ответы должны быть самостоятельными - читатели должны переходить по внешним ссылкам только для более глубокого понимания или для подтверждения источников, и соответствующий контент следует цитировать здесь.

— Томас Оуэнс