Twitter と Instagram のフィードを取得するコードを書いています。コードを書く前に、oAuth について十分に理解したいと思っています。なぜなら、oAuth はそれほど安全ではなく、ほとんどの場合、たとえば公開ツイートにアクセスするときなど、不必要な手間がかかるからです。理解を深めるためにoAuth 2 仕様を読み始めましたが、まだ途中です。そして、たくさんの質問があります。
例としてツイッターを使ってみましょう。ユーザーがサイトにアクセスします。認証のためにそれらを Twitter にリダイレクトし、authorization_grant コードを取得します。ユーザー認証と Web サイトへのリダイレクトは SSL 経由で行われるため、この部分が安全であることは理解しています。Twitter が SSL をサポートするだけで十分ですか?それとも、リダイレクトを安全にするためにサイトも SSL をサポートする必要がありますか? 認証コードが安全でない方法で転送されるのは望ましくありませんよね?
これで、authorization_grant コードを取得したので、サイトはアクセス トークンを取得するために Twitter に要求を送信します。このリクエストを行うと、サイトは authentication_grant コード、クライアント ID、およびクライアント シークレットを送信します。繰り返しますが、これは SSL 経由で行われるため、通信は安全だと思います。しかし、サイトの HTML または Javascript のどこかにクライアント ID とシークレットが含まれている場合、特にサーバー側コードのない静的サイトの場合はどうでしょうか? リダイレクト URL は常にサーバー側のコードで処理する必要があり、サーバー側のコードは HTML や Javascript を介さずにアクセス トークンを要求する必要がありますか?
アクセス トークンを取得したら、それをリクエストに含めて、ユーザーのツイートを取得したり、ユーザーに代わってツイートを投稿したりします。問題のサイトで、クライアント ID とともに HTML または JavaScript 内にアクセス トークンを含める場合も同様です。と秘密、それはかなり安全ではありませんよね？
oAuth のすべてのセキュリティは、ssl と、クライアントの秘密を秘密に保つクライアントの能力に由来するようです。私はこの結論で正しいですか？
もう1つのこと-プロセスの最初のステップで、クライアントがユーザーをTwitterにリダイレクトしてauthorization_grantコードを認証して取得するとき、クライアントIDとシークレットを送信して、2回目のリクエストを行う代わりにアクセストークンを直接取得できます. これが、仕様の暗黙的な方法で彼らが意味するものだと思います。では、なぜアクセス トークンを取得するための 2 番目の要求を送信するこの追加の手順が仕様に追加されたのでしょうか? セキュリティが向上しますか？