LINEログインのIDトークンを検証するには｜デコードと本人確認を分ける

LINEログインのIDトークンをデコードし、ユーザーIDが読めたとしても、その情報をサーバーがそのまま本人のログイン結果として信頼してはいけません。アプリから受け取ったIDトークンは、サーバーで検証してから情報を使います。

ここではIDトークンの検証APIを使う確認方法を説明します。表示名の一致だけで顧客を選ぶ操作や、検証を省く実装例は扱いません。同じ人のユーザーIDがチャネル間で一致する条件は、プロバイダーとユーザーIDの関係で別に確認できます。

デコードは、内容を読めるようにする処理

公式のIDトークンガイドでは、IDトークンはヘッダー・ペイロード・署名からなるJWTとして説明されています。ペイロードにはsubとしてユーザーID、audとしてチャネルID、expとして有効期限などが含まれます。

文字列を読める形へ変えるデコードと、正しい署名・発行元・対象・期限を確認する検証は別です。デコードした内容に名前があったから、本人がログインしたと確定する処理にしないようにします。

公式は、検証コードを実装する方法と、検証エンドポイントを使う方法を案内しています。自分で署名検証を実装する場合は、アルゴリズムと鍵の扱いも必要です。ここでは、公式APIで検証する経路に絞ります。

期待するチャネルIDは、サーバー側で決める

IDトークン検証APIはPOSTを使います。宛先はapi.line.meの/oauth2/v2.1/verifyです。Content-Typeはapplication/x-www-form-urlencodedで、id_tokenとclient_idを指定します。

client_idには、自分のアプリで期待しているLINEログインのチャネルIDを指定します。トークンを送ってきたアプリから渡されたチャネルIDを無条件で採用すると、「自分のチャネル向けか」を確認する意味が薄れます。対象のチャネルを、サーバーの設定やログイン開始時の処理から確定します。

nonceは、認可リクエストで指定した場合、そのときの値を検証リクエストにも指定します。トークンの中から読んだ値を、そのまま期待値にする処理では、開始時の処理と一致したかを確認できません。認可リクエストで指定していない場合は、APIの説明に従って省略します。

同じverifyのURLでも、アクセストークンの検証はGET、IDトークンの検証はPOSTです。名前が似ているため、使うトークンとHTTPメソッドを取り違えないようにします。

図解画像を開く（保存用）

失敗理由は、期限・対象・開始時の処理を分ける

公式リファレンスには、期限切れ、期待したチャネルIDとの不一致、nonceの不一致、署名や形式の不備などのエラーが示されています。失敗をすべて「LINE側の障害」や「ユーザーの操作ミス」にまとめないようにします。

• 期限切れ：古い結果を使い続けていないか確認し、必要なら正規のログインをやり直す案内へ戻します。
• 対象のチャネルが不一致：本番と検証環境、別アプリの設定が混ざっていないかを確認します。
• nonceが不一致：ログイン開始時の処理と、戻ってきた結果の対応を確認します。照合を省略して成功に変えません。
• 形式・署名が不正：正しいIDトークンを受け取っているかを調べ、検証が通るまで顧客情報を使いません。

エラー調査のために、実際のIDトークンやアクセストークンを公開資料・問い合わせ本文・画面へ載せる必要はありません。環境、失敗した段階、エラー分類、再現条件を、秘密値を含めず残します。

検証後も、顧客情報の閲覧権限は別に確認する

検証に成功した結果のsubを、ユーザーIDとして扱います。クライアントが送ってきた別の名前やプロフィールJSONに戻して、顧客を選び直す処理にしないようにします。

ただし、LINEログインが確認できたことと、その人が自社の契約・予約・社内情報を閲覧できることは別です。会員との対応関係や業務上の権限を確認してから、必要な情報だけを表示します。

引き継ぐ際は「IDが読めた」「トークン検証が成功した」「自社の会員と対応づけた」「必要な閲覧権限を確認した」を分けます。一つのIDへつなぐ設計は、同名の人や古いログイン結果へ無理に結びつけることではありません。確認できない場合に情報を表示しない経路まで含めて、担当者が調べられる状態にします。