Happy Web Engineer
Last updated on

OAuth基礎ガイド｜ログインやAPI連携で使われる仕組みをやさしく紹介

はじめに

「Googleアカウントでログイン」「X（旧Twitter）でログイン」といったボタンを見たことがある人は多いと思います。
IDやパスワードを新しく作らずに、普段使っているアカウントですぐにサービスを利用できるのはとても便利ですよね。

この仕組みを支えているのが OAuth（オーオース） という技術です。
OAuthは、Webサービスやアプリが「安全に権限をやり取りする」ための仕組みであり、現代のインターネットに欠かせない基盤技術となっています。

本記事では、初心者や中級者の方に向けて OAuthとは何か・どのように使われているのか・仕組みと活用方法・注意点 をわかりやすく解説します。

OAuthとは？

OAuthは 「他のサービスに権限を安全に渡す仕組み」 です。
正式には Open Authorization の略で、「オープンな認可方式」を意味します。

たとえば、あなたがSpotifyに「Googleアカウントでログイン」したい場合、Spotifyに直接Googleのパスワードを渡してしまうと危険ですよね。
そこでOAuthを使うことで、パスワードを教えることなく「Googleが認証した証拠（アクセストークン）」だけをSpotifyに渡せるようになります。

これにより、

  • パスワードの使い回しを避けられる
  • サービスごとに権限をコントロールできる
  • 安全かつ便利にログインやAPI利用ができる
    といったメリットが得られます。

認証と認可の違い

OAuthを理解する上で大切なのが、認証（Authentication） と 認可（Authorization） の違いです。

  • 認証（Authentication）
    あなたが「誰」であるかを確認すること。
    例：IDとパスワードで本人確認する。
  • 認可（Authorization）
    あなたに「何をしてよいか」を決めること。
    例：Spotifyが「あなたのGoogleカレンダーに予定を書き込む権限」を得る。

OAuthはもともと「認可」を目的に作られた仕組みですが、現在では「ログイン（認証）」用途にも使われるケースが多くあります。

OAuthの登場人物

OAuthの仕組みには、4つの役割が登場します。

  1. リソースオーナー（Resource Owner）
    → データを持っている本人（ユーザー）
  2. クライアント（Client）
    → ユーザーが使うアプリやWebサービス（Spotify、Slackなど）
  3. リソースサーバー（Resource Server）
    → 実際にデータを持っているサーバー（GoogleカレンダーやFacebook APIなど）
  4. 認可サーバー（Authorization Server）
    → ログインや認可を管理するサーバー（GoogleやFacebookの認証サーバーなど）

この4者がやり取りすることで、アプリは「安全にユーザーのデータにアクセスする権限」を得られます。

OAuthの基本フロー

ここでは最もよく使われる「認可コードフロー」を例に説明します。

例：あるアプリがGoogleカレンダーに予定を書き込む場合

  1. ユーザーがアプリで「Googleでログイン」を選ぶ
    → アプリは「Googleに認可を求めたい」とリダイレクトします。
  2. Googleが「このアプリに権限を与えますか？」と確認
    → 「カレンダーにアクセスする権限をこのアプリに与えますか？」と表示されます。
  3. ユーザーが承認する
    → OKを押すと、Googleは「認可コード」をアプリに返します。
  4. アプリが認可コードを使ってアクセストークンを取得
    → アプリは認可サーバーに「認可コードを渡すからアクセストークンをください」と依頼します。
  5. アクセストークンでデータにアクセス
    → アプリはそのアクセストークンを使ってGoogleカレンダーにアクセスし、予定を書き込めるようになります。

OAuthのよくある利用例

OAuthは日常のさまざまな場面で使われています。

  • SNSログイン
    → Google・Facebook・X（旧Twitter）でログイン
  • 外部サービス連携
    → Trelloの通知をSlackに流す
    → NotionからGoogle Driveを利用する
  • モバイルアプリでのログイン
    → LINEアカウントでログインするアプリ

OAuth 1.0とOAuth 2.0の違い

  • OAuth 1.0
    署名ベースで仕組みが複雑。今ではほとんど使われない。
  • OAuth 2.0
    アクセストークン方式でシンプルかつ拡張性が高い。現在の主流。

OAuthとセキュリティ

OAuthは便利ですが、使い方を間違えるとリスクもあります。

  • アクセストークンの漏洩 → 第三者に権限を盗まれる危険
  • 有効期限の管理 → 長すぎると危険、短すぎると使いにくい
  • リフレッシュトークン → 有効期限を安全に更新する仕組み

さらに近年では、モバイルアプリなどでの利用を安全にするため PKCE（Proof Key for Code Exchange） という拡張も使われています。

OAuthの課題と注意点

  • 速度低下の可能性：認証フローが複雑で、最初のログインに時間がかかることがある
  • 法的・契約上の制約：一部の国ではVPNやOAuthの使い方に制限がある場合もある
  • 完全な匿名性はない：Cookieやブラウザ追跡によって補足されるリスクもある

まとめ

  • OAuthは「安全に権限を渡す仕組み」
  • ログイン（認証）やAPI連携（認可）に広く使われている
  • アクセストークンやリフレッシュトークンを使い分けて安全性を確保
  • 初心者でも「Googleでログイン」や「LINEでログイン」の裏側で動いていると理解すればイメージしやすい

関連記事

👉 REST APIとGraphQLの違いをわかりやすく解説｜初心者が理解すべきデータ取得の仕組み
👉 Webエンジニアが理解しておきたいSQLの基本｜データベース操作の第一歩
👉 SQL初心者のためのインデックス入門｜データベースを速くする基本の考え方
👉 学習成果を可視化するGitHub活用法｜コード管理と成長記録の第一歩