GitHub APIを使用してオープンソースプロジェクトを作成したいのですが、ソースコードに秘密鍵が含まれているという問題が発生しました。ソースに秘密鍵を含めないようにさまざまな場所から読んだことがありますが、それに同意します。また、ユーザーに独自のAPIキーを取得させる代わりに、Webサーバーを介した認証に関する漠然とした参照をいくつか見つけました。
私の理解では、次のようになります。
GitHubで認証するときは、ユーザーにサーバーにリクエストを送信してもらいます。そこから、自分のAPIキーを使用してGitHubで認証し、認証が成功した後、リクエストを行ったユーザーに署名を返します。その時点から、GitHubと直接通信できるようになりました。あれは正しいですか？
それがどのように機能するかについては、プロセスについてもう少し知りたいと思います。APIを使用するのは初めてなので、これはかなり新しいです。
私はこの質問に対する答えを受け取ったことがなかったので、その間に見つけたものを伝えたいと思いました。
APIを利用するプロジェクトをオープンソーシングする際の主な懸念事項は、クライアントの秘密を開示することです（少なくとも、GitHubの場合、この質問を投稿したのはそのためです）。ソースにクライアントシークレットを含めないでください。誰かがあなたのクライアントシークレットとクライアントIDを持っている場合、彼らはあなたのアプリケーションを効果的に偽装することができます。
したがって、2つのオプションが残ります。
1）。独自のシンプルなサーバーを実行します。
2）。プロジェクトをフォークするすべての人に、独自のGitHubAPIキーを取得するように要求します。
オプション2を使用することをお勧めします。アプリケーションをオープンソース化すると、それはもはやあなたのものではなくなり、他の人がそれを使って何をするかについては何も言えません。では、クライアントIDとシークレットを使用しているときに、他の誰かのアプリケーションが実行することについて責任を持ちたいのはなぜですか？
ここにも別の問題があります。GitHubで認証して認証トークンを取得したら、その認証トークンをなんらかの方法で安全に保存する必要があります。最初は気づかなかったのですが、基本的にはパスワードです。Auth Tokenをプレーンテキストで保存し、他の誰かがそれを回復した場合、その人はAPIにリクエストを送信し、すべてのユーザーデータを取得できます。（これはOAuth2とベアラートークンを使用しています。）
クライアントに認証トークンを保存する良い方法は実際にはありません。これは、プロジェクトをオープンソース化しようとしているときにも別の問題を引き起こします。オープンソースプロジェクトを使用する人は、基本的に、初期認証と認証トークンの保存に独自のサーバーを使用する必要があります。
覚えておくべきいくつかのこと。