2017-02-01 22 views
0

Amazon Cognitoユーザープールでユーザーを認証するクライアント側アプリケーション(Javaで開発され、Androidではない)があります。状況を明確にするには:アプリケーションにユーザー名とパスワードの入力ダイアログが表示され、SRPメソッドを使用してCognitoユーザープールサービスで認証されます。そのダイアログで潜在的な問題が処理されます(デバイスID、パスワードの変更、2つの要因など)。最後に、プログラムでAWSサービスをユーザーの資格情報とともに使用できる一連のトークンがあります。Amazon Cognito:サーバー側アプリケーションに資格情報を渡す方法

今、カスタムサーバー側アプリケーションと通信するためにクライアントアプリケーションが必要です。クライアントは、そのIDをサーバーアプリケーションに証明する必要があります。サーバーアプリケーションは、より多くのAWSサービスと通信します。ここで、私は2つの異なるユースケースを持っている:

1)サーバーは、クライアント認証されたユーザーが安全な方法で(ですが、ユーザーを偽装せずにを)知っているする必要があります。

2)クライアントはを委任する必要があります。サーバーのユーザーの権限の一部またはすべてを委任します。サーバーはそのユーザーのためにAWSサービスでいくつかのアクションを実行します。

サーバー側アプリケーションは、EC2マシン上で実行されるJavaで開発される可能性が非常に高いです。私は、Cognitoのユーザープールソース(つまり、私はFacebook/Google/OpenIDベースの認証フローに関心がありません)によるユーザーの認証にのみ関心があります。

非常に安全な方法で両方の目的を達成するのはむしろ簡単です。クライアントアプリケーションに、それが付与されたすべてのトークンをサーバーに送信させるだけです。しかし、これは明らかに行く方法ではありません。

しかし、私はCognito User Pool/Cognito Identity Pool/IAM/STSのドキュメントからこれを正しく達成する方法を考え出すのに苦労しています。私は、クライアントアプリケーションがサーバーに渡すことのできる何らかの種類の「委譲トークン」を生成できる可能性を期待しています。サーバはそのトークンを検証し、そこからID情報を抽出(#1を満たす)したり、トークンに対応するアイデンティティを偽装してAWSサービスへの呼び出しを実行することができます(#2を満たす)。あるいは、私はこれを間違って考えていますか?

答えて

3

あなたが指しているのは、現在Amazon CognitoではサポートされていないOAuth 2.0コード許可フローです。

これを行うために現在利用できる安全な方法は、クライアントからサーバーにidトークンを渡し、そのトークンを検証し、そのトークンからID情報を抽出することです。これにより、IDトークンの署名を検証できるので、呼び出し側のIDが証明されます。

+1

私はOAuth 2がこの目的のために特定のフローを持っていたことが気になりましたが、その名前は覚えていませんでした。それを指摘してくれてありがとう。 IDトークンをクライアントからサーバーに共有するのは危険ですか?確かに私はSSL上でそれを渡すことができますが、それでも...それが公開される潜在的なリスクは何ですか?私の特定のサーバーに関して誰かがそのユーザーを偽装する可能性があることは明らかですが、それ以上のことは可能でしょうか? – jwatkins

関連する問題