10sec Tips
10秒tips
LINE連携の落とし穴！トークンを安全に扱う実務設計の鉄則
「LINEログインやLIFFを導入して会員連携をスムーズにしたいけれど、セキュリティ設計は万全だろうか……」そんな疑問や不安を抱えていませんか？
LINE連携で最もやりがちな落とし穴が、「画面側で取得したプロフィール情報をそのままサーバーへ送って認証に使ってしまう」ことです。ブラウザ上の情報は改ざんのリスクがあるため、サーバー側で正規に検証したトークン情報を根拠にする必要があります。
今回は、LIFFやWeb版LINEログインで「何を受け取り、何を確認し、確認後にどう管理すべきか」という実務設計の鉄則をサクッと解説します。
1. 画面の情報をそのまま信じてはいけない
LINE連携の実装で最も重要な基本原則は、「画面側で見えているユーザー情報をそのまま認証・会員識別の根拠にしない」ことです。
ブラウザやアプリ側で取得できるデータは、悪意のあるユーザーによって通信経路上で書き換えられるリスクがあります。クライアントからの自己申告ではなく、サーバー側で正当性を検証した「確認済みトークン」の結果だけを信頼する設計を徹底しましょう。
2. 方式別：トークン確認の流れ
【IDトークン方式（LIFF）】
1. 画面側でIDトークンを取得
2. サーバーへ安全に送信
3. サーバー側でトークンの署名・有効性を検証
4. 検証結果の「sub」を利用者識別子（LINE UID）として扱う
【アクセストークン方式】
1. 画面側でアクセストークンを取得しサーバーへ送信
2. サーバーで有効性を確認
3. 「client_id」および「expires_in」を確認
4. 条件クリア後にプロフィール情報を取得し、利用者を識別
【Web版LINEログイン】
1. コールバックURLで認可コードを受信
2. バックエンドが認可コードをトークンへ交換
3. 取得・確認したトークン情報から利用者を識別
3. やってはいけない！トークンの「保存と使い回し」
「取得したアクセストークンをブラウザのlocalStorage等に保存して次回アクセス時も使い回す」という設計は避けましょう。
⚠️ 注意ポイント
LIFFで取得したアクセストークンは、利用者がLIFFを閉じた時点で、有効期限内であっても無効化される場合があります。再利用を前提にすると「たまにログインできなくなる」といった原因特定の難しい不具合につながります。
LINEのトークンは本人確認の「入口（認証時）」としてのみ使い、確認後は速やかに自社サービスのログイン状態（セッション／Cookieなど）を発行して切り替えるのが安全な設計です。
4. 実装・運用のセキュリティチェックリスト
| フェーズ | チェック項目 |
| ログイン前 | □ redirect_uri は登録済みURLと完全一致（または正規クエリ付き）か□ オープンリダイレクトの脆弱性がないか □ 予測不能な一意の state を毎回生成し、安全な場所に保存しているか |
| ログイン後 | □ 戻ってきた state が開始時の値と一致しているか照合したか |
| 運用・保護 | □ 認証情報の通信はすべてHTTPSで暗号化されているか □ アクセスログや分析基盤にトークンを出力・記録していないか □ 自社セッション用Cookieに Secure / HttpOnly 属性を設定しているか |
🏁 まとめ：安全な土台があってこそLINE連携は成果を生む
LINE連携の安全性は、単にトークンを発行するだけでは担保されません。
「クライアントはトークンの受け渡し」「サーバーは検証と判定」「認証後は自社セッションへ移行」という役割分担を正しく設計し、安全で使いやすいLINEサービスを構築しましょう。
🤝 LINEマーケティング＆開発のご相談はフォーグローブへ
フォーグローブ株式会社は、LINEヤフー社認定の「Technology Partner」（LINEミニアプリ部門／コミュニケーション部門）です。セキュアな認証基盤の構築からLINEミニアプリ開発、CRM連携までトータルで伴走支援いたします。まずはお気軽にご相談ください！
