OAuthフローに関するセキュリティ問題

Question

この質問は、ネイティブモバイルアプリケーションのOAuthベースのログインに関連しています。認可許可タイプのフローに従って、ユーザーはログインページにユーザーID、パスワードを入力し、それに応答して、認可コードがURLで取得されます（URLはhttpsベースの暗号化も機能しません）。

これは、認証コードがプロキシで利用可能であることを意味し、クライアントシークレットを持っていれば誰でも使用できます。モバイル・アプリケーションはセキュリティ保護されていないと考えられているため、クライアント・シークレットはモバイル・アプリケーションに格納することはできません。クライアント・シークレットのセキュリティを迂回するために覚えていたアプローチは、モバイル・クライアントがクライアントID、承認コード、リダイレクトURL。エンドポイントはクライアントシークレットを豊かにし、実際のトークンエンドポイントを呼び出してアクセス権を取得します。 HTTPS経由での通信がすべて行われるため、アクセス権が保護されます。

ここで問題となるのは、URLパラメータの認証コードが安全でなく、脆弱であることです。あるいは、私はセキュリティについて過度に思っています。これが主要な質問です。これが実際にセキュリティ上の問題であれば、緩和策はどのように採用されていますか？

私が考えることができ、古いstackoverflowスレッドの1つから、サーバ側からアクセストークンを与えるトークンエンドポイントを保護するというオプションがありました。どのようにそれを行うにはどのような提案？ - 証明書があれば、証明書はモバイルアプリにパッケージ化され、再び安全ではない）

Answer 1

恥知らずのプラグ...しかし、完全な仕様を読んでオフラインの議論をしたので、同じ。

a。クライアントと認証サーバーの間のTLS - 認可プロバイダ内で数少ないリダイレクトの後に完全な認証が行われると、認可プロバイダは、場所ヘッダー内のクエリパラメータの認証コードとともに、場所ヘッダーをリダイレクトURIとして設定します。認証コードがロケーションヘッダー内にあり、応答ヘッダーがTLSによって保護されているため、盗聴によって認証コードが公開されることはありません。

b。クライアントがモバイルアプリケーションの場合、リダイレクトURIはモバイルアプリ自体を指すカスタムURIスキームを指す必要があります。したがって、ブラウザがロケーションヘッダーに基づいてリダイレクトを実行すると、ブラウザはモバイルアプリを呼び出します。通話はデバイスから出ないので、認証コードは外部に公開されません。

c。クライアントがWebアプリケーションの場合、リダイレクトuriはブラウザ上で実行され、認証コードはプロキシログ（httpsオフロード後）とブラウザキャッシュに公開されます。リダイレクトがある場合は、コードの漏れ認証コードの保護は2通りの方法で行われます。認可コードは生涯で設定することができますが、それは小さくてもかまいません。 b。認証コードは一度しか使用できません。したがって、実際のクライアントが既にそれを使用していた場合、誰も認証コードを再利用してアクセストークンを再度取得することはできません。

d。以下のコメントでKrisが指摘したポイントに基づいて、この仕様では認証コードの誤用を防ぐためのアプローチを定義しています。コードが複数回使用される場合、認可サーバーは、認可コードで作成されたすべてのアクセストークンを取り消すことができます。