2017-02-01 9 views
0

У меня есть клиентское приложение (разработанное на Java, а не Android), которое аутентифицирует пользователя с помощью пула пользователей Amazon Cognito. Чтобы все было ясно: это приложение отображает диалог ввода имени пользователя и пароля, затем аутентифицируется с помощью сервиса пула пользователей Cognito с использованием метода SRP; потенциальные проблемы решаются в этом диалоге (идентификатор устройства, пароль должен быть изменен, два фактора и т. д.). В конце концов, у меня есть ряд токенов, которые позволяют программе использовать службы AWS с учетными данными пользователя.Amazon Cognito: Как передать учетные данные серверному приложению

Теперь мне нужно, чтобы клиентское приложение связывалось с пользовательским серверным приложением. Клиент должен будет подтвердить свою идентичность серверному приложению, которое затем свяжется с большим количеством служб AWS. Здесь у меня есть два разных варианта использования:

1) Серверу необходимо только знать, который является аутентифицированным клиентом пользователем (безопасным манером, но без олицетворения пользователя).

2) Клиент должен делегировать некоторые или все привилегии пользователя на сервер; сервер затем выполнит некоторые действия в службах AWS под этим именем пользователей.

Приложение на стороне сервера, скорее всего, будет разработано на Java, работающем на компьютере EC2. Меня интересует только аутентификация пользователей через источник пула пользователей Cognito (т. Е. Я не заинтересован в потоках аутентификации на основе Facebook/Google/OpenID).

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

Тем не менее, мне сложно узнать из документации Cognito User Pool/Cognito Identity Pool/IAM/STS, как это можно сделать правильно. Я ожидал бы, например, возможность для клиентского приложения иметь возможность генерировать какой-то «токен делегирования», который может быть передан серверу; сервер должен затем иметь возможность проверить этот токен и извлечь из него идентификационную информацию (удовлетворяющий # 1) или олицетворять идентификатор, соответствующий токену, для выполнения вызовов услуг AWS (удовлетворяющих # 2). Или, может быть, я думаю об этом неправильно?

ответ

3

Что вы указываете, это поток подачи кода OAuth 2.0, который в настоящее время не поддерживается Amazon Cognito.

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

+1

У меня было некоторое слабое воспоминание о том, что для этой цели у OAuth 2 был определенный поток, хотя я не мог запомнить его имя. Спасибо за это. Теперь, не рискованно делиться маркером идентификатора с клиентом на сервер? Конечно, я могу передать это через SSL, но все же ... Каким будет потенциальный риск его раскрытия? Существует очевидный факт, что кто-то может олицетворять пользователя в отношении моего конкретного сервера, но можно ли сделать больше, чем это? – jwatkins