LINEログインとは？仕組み・できること・会員基盤としての判断ポイント

LINEログインは、ユーザーが自分のLINEアカウントで会員登録・ログインできる機能です。多くの解説は「入力の手間が減る」という利便性で語りますが、実務で本当に問われるのはその先です。顧客のIDをどこに置き、どう一本化し、誰が保守するのか——LINEログインの導入は、突き詰めれば会員基盤をめぐる意思決定になります。この記事は、その全体像を一枚の地図として示すハブです。まず仕組みを標準仕様（OAuth 2.0 / OpenID Connect）のレベルまで分解し、受け取れる情報、公式アカウントとの違い、そして「作るか買うか」「会員基盤としてどう設計するか」までを順にたどります。個々のテーマは、それぞれの深掘り記事へつなげていきます。ソーシャルログイン全般の位置づけは 「ソーシャルログインとは？」 もあわせてどうぞ。

仕組み——OAuth 2.0 と OpenID Connect で「認証を借りる」

LINEログインは、OAuth 2.0 の認可コードフローと、その上で本人確認（認証）を標準化する OpenID Connect（OIDC） にもとづいています。核心は、パスワードを自社で預からず、認証そのものはLINEに委ねるという一点です。ユーザーの手間と、事業者側のパスワード管理リスクを同時に減らせるのは、この委譲があるからです。処理は次の順に進みます。

第一に、自社サービスはユーザーのブラウザを認可エンドポイント https://access.line.me/oauth2/v2.1/authorize へ送り出します。このとき response_type=code に加えて、チャネルIDを表す client_id、認可後に戻ってくる先の redirect_uri、要求する権限を空白区切りで並べた scope、そして後述する state と nonce を付けます。第二に、LINE側でユーザーが認証（ログイン）と同意（許可）を行います。ここは完全にLINEの画面であり、自社サーバーはパスワードに一切触れません。第三に、同意が済むとLINEはユーザーを redirect_uri に戻し、その際に一度きり有効な認可コードと、送っておいた state を返します。第四に、自社サーバーがそのコードをトークンエンドポイント https://api.line.me/oauth2/v2.1/token に送り、チャネルシークレット（client_secret）を添えて交換します。引き換えに得られるのがアクセストークンと、OIDCの中心であるIDトークン、そしてトークンを更新するためのリフレッシュトークンです。アクセストークンには有効期限があり、切れたらリフレッシュトークンで更新する——この寿命管理も、あとで「自前実装の保守」の話に効いてきます。

この四段階で押さえるべきは、認可コードを受け取るのはブラウザ（フロント）でも、それをトークンに換えるのはサーバーだという分担です。チャネルシークレットはサーバーだけが持つ秘密であり、これがフロントに漏れない設計だからこそ、第三者が認可コードを横取りしてもトークンには換えられません。取得できる情報の詳細は 「LINEログインで取得できる情報」 にゆずり、ここではまず仕組みの骨格を通します。

state・nonce・PKCE——「借りた認証」を守る三つの仕掛け

認証を外部に委ねる以上、その往復を横取り・偽装されない備えが要ります。役割の異なる三つを分けて理解すると、実装の勘所が見えます。state はCSRF（クロスサイトリクエストフォージェリ）対策です。ログイン開始時にセッションごとのランダム値を生成して送り、戻ってきた値と照合します。一致しなければ、そのコールバックは自分が始めた往復ではない、と判断して弾けます。nonce はリプレイ攻撃対策で、送った値がIDトークンの中に埋め込まれて返るため、受け取ったIDトークンが「今回の要求に対する新しい応答」であることを確認できます。そしてPKCEは、code_challenge（code_verifier をSHA-256でハッシュし code_challenge_method=S256 として示した値）を最初に送っておき、トークン交換時に元の code_verifier を提示させる仕組みで、認可コードを盗まれても、それだけではトークンに換えられないようにします。LINEログインはPKCEに対応しており、とりわけモバイルアプリのように秘密を安全に保持しにくいクライアントで効果を発揮します。三つとも「あってもなくても動く」ように見えて、外部認証を安全に成立させる土台です。

受け取れる情報——アクセストークンとIDトークンは役割が違う

「LINEログインで何が取れるか」は、どのトークンを、どの scope で受け取ったかで決まります。まず scope は要求する権限で、代表的な三つがあります。要求しなかった情報は返らない——つまり、必要なものだけを最小で取るのが基本の設計です。

受け取り方には二つの経路があり、性格がはっきり違います。アクセストークンは、LINEプラットフォーム上のユーザーデータにアクセスするための「許可証」です。これを添えてプロフィールAPI（GET https://api.line.me/v2/profile）を呼ぶと、userId・displayName・pictureUrl・statusMessage というその時点の最新プロフィールが返ります。表示名やアイコンは後から変わり得るので、「今の値がほしい」ときはこちらです。いっぽうのIDトークンは、ユーザー情報を含む改ざん検知可能なJWTで、「確かにこの人がLINEで認証された」という証明そのものです。ログイン成立の根拠として使うなら、APIを呼び直すより、この一枚を検証するほうが筋がよいわけです。

IDトークン（JWT）の中身と検証——Web版は HS256、LIFF・ネイティブは ES256

IDトークンのペイロードには、発行者を示す iss（https://access.line.me）、ユーザーを一意に識別する sub（＝userId）、宛先のチャネルIDである aud、有効期限 exp、発行時刻 iat、先ほどの nonce、そして scope に応じた name・picture・email が含まれます。受け取ったら、必ず署名と主要クレームを検証します。具体的には、署名が正しいこと、iss がLINEであること、aud が自社のチャネルIDと一致すること、exp が切れていないこと、そして送った nonce と一致することを確かめます。ここを省くと、他サービス向けに発行されたトークンの使い回しなどを見抜けません。

実装で見落としやすいのが署名アルゴリズムの違いです。ウェブ版のLINEログインで発行されるIDトークンは HS256（共通鍵方式）で署名され、その鍵はチャネルシークレットです。共通鍵である以上、検証はチャネルシークレットを安全に保持できるサーバー側で行う必要があり、この値をフロントに出してはいけません。対してLIFFアプリやネイティブSDK経由で得るIDトークンは ES256（公開鍵方式）で、LINEが公開する鍵（JWKセット。トークンヘッダーの kid で該当する鍵を選ぶ）で検証します。手早く済ませたいときは検証エンドポイント https://api.line.me/oauth2/v2.1/verify に id_token と client_id を送れば、妥当性チェックとデコード済みプロフィールをまとめて受け取れます。いずれにせよ、LINEから直接得たのでない限り、IDトークンはサーバーで検証する——これが原則です。

アクセストークンは「今の情報を取りにいく許可証」、IDトークンは「本人が認証された証明書」。取得手段が違えば、使いどころも変わります。

できること——ログインだけではありません

仕組みを踏まえると、LINEログインでできることは大きく四つに整理できます。第一に会員登録の簡略化。profile や openid で得た表示名・画像・（審査済みなら）メールが自動で入り、入力項目をほぼゼロに近づけられます。第二に自動ログイン。ユーザーがすでにLINEにログイン済みなら、サイトごとのID・パスワードを打たずにそのまま入れます。第三に、LINEならではの友だち追加の同時完了。ログインと同じ導線で、LINE公式アカウントの友だち追加まで済ませられます。第四にID連携。自社の会員IDとLINEの userId を結びつけ、その後のセグメント配信やCRMにつなげます。ログインが、その後の顧客接点づくりと地続きになる——この性格が、ほかのソーシャルログインとの大きな違いです。

友だち追加まで一度に——bot_prompt と「同一プロバイダー」要件

三つ目の「友だち追加の同時完了」は、認可URLに bot_prompt を付けることで実現します。値は二つあり、normal は同意画面の中に友だち追加の選択肢を控えめに表示し、aggressive は同意のあとに友だち追加専用の画面を挟んで、より積極的に促します。追加を最大化したいキャンペーン導線では aggressive、体験を軽く保ちたい常設導線では normal、と使い分けるのが定石です。前提として、LINEログインのチャネルと、友だち追加させたいLINE公式アカウント（Messaging APIチャネル）が同じプロバイダーに属している必要があり、両方の管理権限も要ります。友だちになったかどうかは、コールバックに返る friendship_status_changed で分かるほか、フレンドシップ状態を返すAPI（friendFlag）でも確認できます。ログインという「認証」と、公式アカウントという「配信チャネル」が、ここで一本の導線に合流します。

ウェブアプリ版と LIFF 版——同じLINEログインでも入れ方が違う

LINEログインには、大きくウェブアプリ版とLIFF版の二つの入れ方があります。ここまで説明してきたブラウザのリダイレクトで完結するのがウェブアプリ版で、自社のWebサイトやWebサービスに「LINEでログイン」を置く標準的な形です。認可エンドポイントへ飛ばし、コールバックで認可コードを受け、サーバーでトークンに換える——先ほどの四段階そのものです。

いっぽうLIFF（LINE Front-end Framework）版は、LINEアプリ内のブラウザ（WebView）で動くWebアプリとして組み込みます。リッチメニューや公式アカウントのトークからLIFF URLを開くと、LINEにログイン済みのユーザーは改めての同意なく利用でき、liff.getProfile() で userId や表示名を、liff.getIDToken() でIDトークンを取得できます。先に触れたとおり、LIFF経由のIDトークンは ES256 署名である点が、検証の実装に効いてきます。

使い分けの目安は明快です。自社サイト・アプリを入口にするならウェブアプリ版、LINEアプリの中での体験（会員証や来店時の画面など）を作るならLIFF版。LINE内で完結する会員証づくりは 「デジタル会員証を作る」 で具体的に扱っています。

混同されがちな「LINE公式アカウント」との違い

実務で必ずつまずくのが、LINEログインとLINE公式アカウントの取り違えです。LINEログインは“自社サイト・アプリの認証”の仕組み、LINE公式アカウントは“メッセージを配信するチャネル”で、役割がまったく違います。よくあるのが「LINEログインを入れれば配信もできる」という誤解ですが、配信は公式アカウント（Messaging API）側の機能です。両者を同一プロバイダーの下でID連携したときに初めて、「ログインした会員に、公式アカウントから配信する」という一連の流れが成立します。先ほどの bot_prompt は、まさにこの連携を入口の段階で自動化する仕掛けだと捉えると、位置づけが腑に落ちます。

なぜ、日本ではLINEなのか

日本のソーシャルログインは、LINEが突出しています。ソーシャルPLUSの利用状況調査（2025年・対象354サイト）によれば、ソーシャルログインが設置されたサイトでの利用のうち、利用回数の約88%・利用ユーザー数の約87%をLINEログインが占め、その97%がスマートフォン経由でした。注意したいのは主語です。これは「日本人の9割がLINEでログインしている」ではなく、「ソーシャルログインが使われる場面の中で、LINEが大半を占める」という意味です。とはいえ、その背景にある国内の月間利用者数が1億人（2025年12月末時点）という規模を踏まえれば、スマホ主体のBtoCサービスでLINEログインを主軸に据えるのは、合理的な判断だといえます。

作るか、買うか——導入の判断

導入方法は「自前で実装する」か「SaaS／IDaaSを使う」かに大別されます。ここは中立に考えるべきところです。自前で実装するとは、認可リクエストの組み立て、コールバックの受け取り、state の生成と照合、IDトークンの署名検証（Web版なら HS256）、アクセストークンの失効・更新、そして既存会員DBへの userId の保存と紐付けまで、すべてを自社で持ち、保守し続けるということです。しかも一度作れば終わりではありません。LINEログインは現行が v2.1 で、旧 v2.0 は非推奨、さらに古い v1 はすでに提供終了しています。仕様は変わり続け、それに追随する保守コストが発生するのです。だからこそ、トラフィック規模・内製リソース・監査やセキュリティ要件・総保有コスト（TCO）を並べて選ぶべきで、その判断軸は 「認証は作るか買うか」 にまとめています。

会員基盤としての設計——ここが本質です

最後に、いちばん大事な視点です。LINEログインの導入は、「ボタンを置く」話ではなく「会員のIDをどう設計するか」の話です。鍵になるのがユーザーID（userId）です。これは同一プロバイダーの中でユーザーを一意に識別する“変わらない値”で、しかも同じプロバイダー配下のLINEログインチャネルとMessaging APIチャネルでは、同じ userId が返ります。つまり設計次第で、ログインで得たIDと配信のためのIDを確実に名寄せできる——ここがLINEを会員基盤の軸に使える理由です。

ただし、userId をそのまま会員の主キーにするのは危うい選択です。堅い設計は、認証（誰であるか＝CIAM）と、会員データ（何を買い、どう接点を持ったか＝CRM／CDP）を分け、自社の内部会員IDを“正”として持ったうえで、そこにLINEの userId を外部識別子として紐付ける形です。こうしておけば、同じ人が「メールで登録した会員」と「LINEで登録した会員」に分裂する二重会員を防げますし、後からログイン手段を足しても主キーは揺れません。逆に、この名寄せの設計を怠ると、二重会員と、それに伴う配信・分析の齟齬が積み上がっていきます。

会員基盤の“核”を外部のIDに預ける以上、単一障害点への備えは避けて通れません。

あわせて考えるべきが単一IdP依存のリスクです。LINE側の障害や規約変更、アカウント停止が起きると、そのIDに依存したログインは止まります。だからこそ、メールやほかのログイン手段を代替として併設し、アカウントの復旧経路を用意しておく。さらに、会員という“事業の資産”をどこまで外部IDに委ね、どこからを自社のIDマスタで正とするか——このデータ主権とロックインの線引きまで含めて設計するのが、あとで後悔しない会員基盤です。その全体設計は 「会員基盤の正しい作り方」 に整理しています。

ここから深掘り