2025/04/22 04:45 OAuth Explained
ロボ子、今日のニュースはOAuthについてじゃ。
OAuthですか。確か、LinkedInがGoogleの連絡先をインポートする際に使われている認証の仕組みでしたよね。
そうじゃ、その通り！OAuthは、ユーザーが自分のGmailのメールアドレスとパスワードをLinkedInに直接入力しなくても、安全に認証・認可を行うためのものじゃ。
なるほど。具体的にはどのような流れになっているんですか？
まず、ユーザーがLinkedInで「Google連絡先をインポート」をクリックするじゃろ。すると、LinkedInがユーザーをGoogleのOAuth同意ページにリダイレクトするのじゃ。
そこでユーザーがログインしてアクセスを承認するんですね。
そうじゃ。GoogleはLinkedInにワンタイムコードを付けてリダイレクトする。そして、LinkedInがそのコードを使ってGoogleからアクセストークンを取得するのじゃ。
アクセストークンを使って、LinkedInがGoogleのAPIを呼び出して連絡先を取得するんですね。認証の仕組み、奥が深いですね。
じゃろじゃろ？LinkedInがGoogle APIアカウントを設定して、`client_id`と`client_secret`を受け取るのが最初じゃ。
`client_id`はGoogleがLinkedInを識別するためのID、`client_secret`は秘密鍵ですね。
その通り！そして、LinkedInがユーザーをGoogleの認証エンドポイントにリダイレクトする際に、`client_id`、`redirect_uri`、`scope`を渡すのじゃ。
`redirect_uri`はGoogleがリダイレクトするURI、`scope`はLinkedInがGoogleに要求するアクセス範囲ですね。
そうじゃ。ユーザーがGoogleでログインして同意すると、Googleがワンタイム認証コードを生成して`redirect_uri`にリダイレクトする。
そのコードをLinkedInがGoogleのトークンエンドポイントに送信して、アクセストークンとリフレッシュトークンを受け取るんですね。
OAuth 2.0では、HTTPSを使って`client_secret`やアクセストークンなどの機密データを保護しているのじゃ。
セキュリティ対策も重要ですね。`state`パラメータを使ってCSRF攻撃を防ぐとありましたが、具体的にはどういうことですか？
`state`パラメータは、LinkedInが生成したユニークなランダム値を認証リクエストに含めることで、リクエストが攻撃者ではなくユーザーからのものであることを保証するのじゃ。
なるほど。LinkedInは、`state`が元の値と一致することを確認するんですね。
OAuth 1.0では、クライアントがすべてのリクエストに暗号署名する必要があって複雑だったが、OAuth 2.0ではHTTPSを使ってデータ転送を保護し、署名付きリクエストの代わりにベアラートークンを使うことで、簡素化されたのじゃ。
セキュリティと利便性のバランスが取れているんですね。勉強になりました！
ところでロボ子、OAuthって、お餅みたいじゃな。認証（おー、認証！）って感じで…
博士、それはちょっと無理がありますよ！
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。