web-dev-qa-db-ja.com

IN OAuth 2.0、クライアントの秘密はどのようにして秘密にしておくべきですか？

ほとんどのOAuth 2.0フローを使用すると、クライアントアプリケーションは、「クライアントID」と「クライアントシークレット」を使用して、認証サーバーに対して自身を識別できます。

OAuth 2の仕様では、クライアントの秘密は確かに秘密にしておくべきであると述べています。

ただし、クライアントシークレットがアプリケーション内にある場合、それはシークレットではありません。誰かがデバッガ、逆アセンブラなどを使用して表示できます。

したがって、このクライアントシークレットの有効性や目的がわかりません。さらに、一般大衆の管理下にあるクライアントのクライアントシークレットを保護するための推奨事項はありますか？ここでの目的は、リソースの所有者（ユーザー）とは関係なく、クライアントアプリケーションと承認サーバーの間に何らかの信頼関係を確立することです。

最後に、OAuthフローをクライアントシークレットなしで使用する場合と、クライアントシークレットを使用してフローを使用し、実際にその「クライアントシークレット」を保持しない場合の違いは何ですか？

oauthoauth2secrets-management
1
the_endian

OAuth2 指定 は2種類のクライアントを定義します

   confidential
      Clients capable of maintaining the confidentiality of their
      credentials (e.g., client implemented on a secure server with
      restricted access to the client credentials), or capable of secure
      client authentication using other means.

   public
      Clients incapable of maintaining the confidentiality of their
      credentials (e.g., clients executing on the device used by the
      resource owner, such as an installed native application or a web
      browser-based application), and incapable of secure client
      authentication via any other means.

また、使用クライアントシークレットは機密クライアントにのみ適用されます。

つまり、基本的には、安全なサーバーに安全に常駐できる場合にのみ使用し、リッチクライアント（デスクトップ、モバイル、ブラウザーのJavaScript）の場合は使用しません。

クライアントシークレットの目的は、クライアントの偽装を防ぐことです。あなたが気づかなかったように、誰もがエンドユーザーアプリケーションから資格情報を抽出して、自分でOAuthフローを実行できます。ただし、シークレットが安全なサーバー側である場合、フローを完了してトークンを取得することはできません。

一般大衆の管理下にあるクライアントでクライアントシークレットを使用することに関しては、セキュリティの観点からは何も追加しないため、まったく使用しないことをお勧めします。

2
AGrzes