OAuth client_secretファイルをJavaアプリケーションに含める
client_secret.jsonファイルは、GoogleドライブAPIのOAuth 2.0認証フローで使用されます（ 例 ）。
Javaアプリケーションにclient_secret.jsonを含めると、JARコンテンツへのアクセスが非常に簡単になります。心配する必要がありますか？このファイルを「秘密」にする方法はありません。
この情報で何が悪いのでしょうか？最後のユーザーは、hisGoogleドライブファイルにアクセスするために、アプリケーションへのアクセスを許可する必要があります。
更新：2つのケースを分析できるようです。
client_secret.jsonでのみ何ができますか？
これが私の最初の質問の意図でした。私が考えられる唯一のことは、ユーザーが自分のアカウントを私のアプリにリンクすると、Drive APIの無料割り当て（1,000,000,000リクエスト/日）を使い果たす可能性があるということです。
- 誰かがユーザーの保存された資格情報（例では
StoredCredentialファイル）にclient_secret.jsonをアクセスします。
これは最悪のケースだと思います。その「誰か」がユーザーアカウントで私のアプリとして機能する可能性があるためです。
更新2：Googleドキュメントはここにあります： sing OAuth 2.0 for Installed Applications
Developers Consoleから取得したクライアントIDとクライアントシークレットは、アプリケーションのソースコードに埋め込まれています。このコンテキストでは、クライアントシークレットは明らかにシークレットとして扱われません。
javascript/desktop/mobileアプリケーションにクライアントシークレットを含めないでください
その理由は、あなたが言ったように、アクセスが非常に簡単だからです。アプリケーションに組み込んだ場合は保護できません。攻撃者がクライアントシークレットを見つけると、クライアントを偽装できるようになります。クライアントシークレットは、Webサーバーに含まれることのみを目的としています。
OAuth2暗黙的フローを使用
OAuth2 Implicit Flowは、その問題を解決するために特別に設計されました。暗黙的なフローでは、クライアントシークレットはありません。ユーザーがOAuth2プロバイダーで認証されると、クライアントは直接アクセストークンを受信するため、クライアントシークレットは必要ありません。
https://tools.ietf.org/html/rfc6749#section-1.3.2
認証に暗黙フローを使用しないでください
OAuth2は、認証とは異なる承認用に作成されました。認証が必要な場合は、OAuth2の上に構築されたOpen ID Connectを調べて、安全な認証に必要なすべての不足部分を提供する必要があります。
セキュリティについて
Javascript/desktop/mobileクライアントを使用する場合は、Implicit Flowを使用することをお勧めしますが、必要なラウンドトリップの数を減らすための便宜のためです。クライアントシークレットは保護できないため、含める必要はありません。
クライアントシークレット（およびそれに関連付けられている追加の手順）を削除することの1つの欠点は、トークンが特定のクライアントにバインドされていないため、トークンが発行されたかどうかをクライアントが知ることができないことです。これにより、次のようなフィッシング攻撃の機会が複数発生します。