LINEログインのログインフローを理解して使う
 minako-ph LINE DC Frontend Meetup #1


自己紹介
 ・山本美奈子（minako-ph）
 ・株式会社LayerX
 ・ソフトウェアエンジニア
 ・LINE API Expert
 ・LINE APIを用いたウェブアプリケーションの開発
 ・電子工作と組み合わせて日常をラクにする開発


No content

みなさんこの図を見たことがありますか？


🙆 LINEログインのログインフローですね。


今日はこのログインフローを詳しく見ていこうと思います


LINEログインの安全さを理解したうえで、
 プロダクトに導入できる人を目指しましょう🚀


まずは、ドキュメントを読んでみる


まずは、ドキュメントを読んでみる
 
 ウェブアプリ向けのLINEログインの処理（ウェブログイン）は、OAuth 2.0の認可コード 付与のフローとOpenID Connect プロトコルに基づいています。ウェブログインのフ ローの概要は以下のとおりです。


まずは、ドキュメントを読んでみる
 
 ウェブアプリ向けのLINEログインの処理（ウェブログイン）は、OAuth 2.0の認可コード 付与のフロー とOpenID Connectプロトコルに基づいています。ウェブログインのフ ローの概要は以下のとおりです。


まずは、ドキュメントを読んでみる
 
 ウェブアプリ向けのLINEログインの処理（ウェブログイン）は、OAuth 2.0の認可コード 付与のフロー とOpenID Connectプロトコルに基づいています。ウェブログインのフ ローの概要は以下のとおりです。


まずは、ドキュメントを読んでみる
 
 OAuth 2.0…？OpenID Connect (opens new window)プロトコル...？


もう一度ログインフローを見てみる


もう一度ログインフローを見てみる
 1. ユーザーがWebアプリにログインを試みます。 
 2. Webアプリはユーザーを LINEプラットフォームの認可 URLにリダイレクトしま す。このURLにはredirect_uri（リダイレクトされた後にユーザーが戻るべき WebアプリのURL）とstate（CSRF攻撃を防ぐためのランダムな文字列）が含ま れます。
 3. ユーザーはLINEログイン画面で認証を行います。 
 4. 認証が成功すると、ユーザーは同意画面にリダイレクトされ、アクセスを承認し ます。
 5. 承認後、ユーザーは認可コードが Queryに付与されたredirect_uriにリダイレ クトされます。この時、送信された stateと受け取ったstateが同じであることを Webアプリは検証します。 
 6. Webアプリは認可コードを使ってアクセストークンを要求します。 
 7. LINEプラットフォームはアクセストークンを発行します。 
 8. Webアプリはこのアクセストークンを使用して、 LINEプラットフォームからユー ザープロファイル情報を取得します。 
 9. 最終的に、ユーザーはログインし、プロファイル情報が表示されます。 


もう一度ログインフローを見てみる
 1. ユーザーがWebアプリにログインを試みます。 
 2. Webアプリはユーザーを LINEプラットフォームの認可 URLにリダイレクトしま す。このURLにはredirect_uri（リダイレクトされた後にユーザーが戻るべき WebアプリのURL）とstate（CSRF攻撃を防ぐためのランダムな文字列）が含ま れます。
 3. ユーザーはLINEログイン画面で認証を行います。 
 4. 認証が成功すると、ユーザーは同意画面にリダイレクトされ、アクセスを承認し ます。
 5. 承認後、ユーザーは認可コードが Queryに付与されたredirect_uriにリダイレ クトされます。この時、送信された stateと受け取ったstateが同じであることを Webアプリは検証します。 
 6. Webアプリは認可コードを使ってアクセストークンを要求します。 
 7. LINEプラットフォームはアクセストークンを発行します。 
 8. Webアプリはこのアクセストークンを使用して、 LINEプラットフォームからユー ザープロファイル情報を取得します。 
 9. 最終的に、ユーザーはログインし、プロファイル情報が表示されます。 


もう一度ログインフローを見てみる
 どこがOAuth 2.0で、どこがOpenID Connectに あたるのだろう...？どうしてこんなにフローを踏む 必要があるのだろう...？


もう一度ログインフローを見てみる
 
 OAuth 2.0とOpenID Connectについて理解しながら見ていきましょう


OAuth 2.0の認可コードの付与のフローとは（LINEプラットフォームの例）
 ユーザーの安全な認証と、その同意に基づくデータアクセスを可能にするための一連の ステップです。このプロセスでは、ユーザーが自身のLINEアカウントを使用して第三者 のクライアントアプリケーション（例: Webサービスやモバイルアプリ）にリソースサー バー（LINEプラットフォーム）上のデータへのアクセスを許可します。


OAuth 2.0の認可コードの付与のフローとは（LINEプラットフォームの例）
 1. ユーザーのリダイレクト
 2. ユーザー認証
 あなたの情報をLINEから貰いたいから ログインしてきてやー
 おっけー
 ログインっと。
 おー。メアドもパスワードも合って る。本当にこのユーザーは言ってい る通りの人物だ。


OAuth 2.0の認可コードの付与のフローとは（LINEプラットフォームの例）
 3. アクセス承認
 4. 認可コードの取得
 チケットアプリにあなたの名前とメールア ドレスを渡してもいい？
 いいよ〜
 お、LINEから「秘密の合言葉」を貰えた。これ が認可コードか。これを使ってユーザー情報 の取得ができそうだ


OAuth 2.0の認可コードの付与のフローとは（LINEプラットフォームの例）
 5. アクセストークンの交換
 さっきもらった「秘密の合言葉」（認可コード） はこれ！これで本当に私たちはユーザー情 報にアクセスしてもいいの？ 
 いいよー。ユーザーの情報を見ることができ る特別なパス（アクセストークン）を渡しておく ね。


OAuth 2.0の認可コードの付与のフローとは（LINEプラットフォームの例）
 6. リソースへのアクセス
 その特別なパス（アクセストークン）を使うと、 LINEのデータボックスが 開いて、ユーザーが許可した情報を安全に取り出せるみたいだ！これ で、ユーザーの必要な情報を見ることができるぞー 


OAuth 2.0の認可コードの付与のフローとは（LINEプラットフォームの例）
 
 ・主なフローのステップ 
 1. ユーザーのリダイレクト : クライアントアプリケーションはユーザーを LINEのログインページへリダイレクト し、認証を要求します。 
 2. ユーザー認証: ユーザーはLINEアカウントでログインし、自分の身元を確認します。 
 3. アクセス承認: LINEの認可画面でユーザーはクライアントアプリケーションが特定の情報にアクセスする ことを承認します。
 4. 認可コードの取得: 承認後、LINEプラットフォームはクライアントアプリケーションに認可コードを発行しま す。
 5. アクセストークンの交換 : クライアントアプリケーションは認可コードを LINEプラットフォームに送信し、アク セストークンと交換します。 
 6. リソースへのアクセス : アクセストークンを使用して、クライアントアプリケーションは LINEプラットフォーム 上でユーザーのデータにアクセスします。 


OAuth 2.0の認可コードの付与のフローとは（LINEプラットフォームの例）
 
 ・ポイント
 
 ● 間接的なトークン配布 : ユーザーの認証情報は第三者アプリに直接渡され ず、一時的な認可コードを介して間接的にアクセストークンが交換されるた め、情報漏洩のリスクが減少します。 
 ● 限定的なアクセス: アクセストークンはユーザーが承認した情報や機能へのア クセスのみを提供し、全てのユーザーデータへのアクセスを許可しないため、 ユーザーのプライバシーを保護します。 
 ● 短命の認可コード: 認可コードは短期間で失効するため、仮に盗まれたとして も安全性が保たれます。 
 ● ユーザーは安心して第三者アプリを利用でき、サービス提供者は信頼性を高 めることができます。 
 


OAuth 2.0の認可コードの付与のフローとは（LINEプラットフォームの例）
 
 というのが、OAuth 2.0の認可コードの付与のフローでした。 


OpenID Connect プロトコルとは（LINEプラットフォームの例）
 
 次にOpenID Connect プロトコルについて見ていきましょう！ 


OpenID Connect プロトコルとは（LINEプラットフォームの例）
 OpenID ConnectはOAuth 2.0をベースに、ユーザーの認証情報を管理する拡 張です。このプロトコルにより、ユーザーはLINEで一回ログインするだけで、その情 報を他のアプリと安全に共有できます。これによって、繰り返しログインする手間が 省け、一度の認証で複数のサービスを簡単に使えるようになります。


OpenID Connect プロトコルとは（LINEプラットフォームの例）
 1. ユーザー認証
 ログインっと。チケットアプリへの情報共 有も許可っと。
 あなたがAさんであることを確認できまし た。ログインしているのは間違いなくAさ んですね


OpenID Connect プロトコルとは（LINEプラットフォームの例）
 
 2. IDトークンの発行
 Aさんが正しくログインし、情報共有に同意し たことを確認したので、 IDトークンを発行しま す〜
 IDトークンをチェックした結果、 Aさんがログ インしていることがわかったぞ 
 3. ユーザー情報の取得


OpenID Connect プロトコルとは（LINEプラットフォームの例）
 
 こちらのアプリにもAさんとして安全にログイ ンっと。これからAさん専用のセッションを開 始
 4. セキュアなセッションの確立


OpenID Connect プロトコルとは（LINEプラットフォームの例）
 
 
 ・主なフローのステップ 
 1. ユーザー認証: ユーザーは自分のLINEアカウント情報を使って LINEプラットフォームでログインします。 これにより、ユーザーは自分が誰であるかを証明します。 
 2. IDトークンの発行: LINEプラットフォームは、ユーザーの身元を証明する IDトークンを発行します。この トークンは、ユーザーが LINEプラットフォームで正しく認証されたことを示します。 
 3. ユーザー情報の取得 : 認証された後、ユーザーはクライアントアプリケーションに自分の情報を共有する ための同意を与えます。クライアントアプリケーションは、 IDトークンを使用してユーザーの基本情報を得 ることができます。
 4. セキュアなセッションの確立 : アプリケーションはユーザーの認証情報を確認した後、安全なセッションを 確立します。これにより、ユーザーはその後の訪問で再度ログインすることなく、アプリケーションを利用で きるようになります。 


OpenID Connect プロトコルとは（LINEプラットフォームの例）
 
 ・ポイント
 ● 直接的なユーザー認証: LINEプラットフォームが直接ユーザーを認証するため、アプリ ケーションは安全にユーザー情報を扱うことができます。 
 ● トークンベースのアイデンティティ情報 : IDトークンにより、ユーザーはパスワードなどのセ ンシティブな情報をアプリケーションと共有することなく、自身を安全に認証できます。 
 ● ユーザー情報のコントロール: ユーザーはどの情報を共有するかを選択でき、プライバ シーを保護できます。
 ● セキュリティプロトコルの活用: OpenID Connectはセキュアな通信プロトコルを使用し て、情報の安全な交換を保証します。 
 ● ユーザーは一度のログインで複数のアプリケーションにアクセスでき、利便性が向上しま す。


OAuth 2.0とOpenID Connect
 それぞれをまとめると 
 
 OAuth 2.0の認可コード付与のフローとは・・・ 
 OAuth 2.0は、ユーザーが第三者アプリにデータアクセスを安全に許可するための認可プロセスです。ア クセストークンを介して、信頼できるデータ共有が可能になります。 
 
 OpenID Connectとは・・・
 OAuth 2.0の基盤の上に構築されたプロトコルで、アプリケーションがユーザーの「認証」を行うための追 加的なメカニズムを提供します。ユーザーが自身をアプリに証明するための仕組みを加えます。シングル サインオンを可能にし、 OAuthの認可フレームワークに認証の安全性を強化します。 
 


さっきのこの図に戻りましょう


No content

もう一度ログインフローを見てみる
 ・Log in
 
 ユーザーがログインを試みる 
 
 ユーザーはWebアプリケーションを通じて LINEプラットフォームにログインを試み ます。このプロセスは OAuth 2.0のフレームワークに基づいており、ユーザーが自 らを認証し、アプリケーションに自分の情報へのアクセス許可を与えることを意味し ます。
 


もう一度ログインフローを見てみる
 ・Access the LINE Login authorization URL with `redirect_uri` and `state`
 
 ログイン認証画面へのアクセス 
 
 「Web app」は、ユーザーをログイン認証を行う「 LINE Login画面」にリダイレクト します。このURLには、ユーザーが認証後に戻るべき場所を示す redirect_uri と、セッションを特定しセキュリティを保つための stateが含まれています。これは OAuth 2.0プロトコルに従った標準的な手続きで、ユーザーが自身の LINEアカウ ントで安全にログインできるようにするためのものです。 
 


もう一度ログインフローを見てみる
 ・LINE Login screen / Authentication
 
 ユーザー認証
 
 ユーザーは「LINEログイン画面」で自分のアカウント情報を使用してログインし、 自分自身を認証します。これは OpenID Connectプロトコルに沿ったステップで、 ユーザーが自分の身元を安全に証明するためのプロセスです。この認証を通じ て、ユーザーは自分が誰であるかをアプリケーションに確かめてもらうことができま す。
 


もう一度ログインフローを見てみる
 ・Consent screen / Authorization
 
 
 同意画面での承認
 
 ユーザーは「同意画面」で、「 Web app」が自分の情報にアクセスすることを許可 するかどうかを選びます。これは OAuth 2.0プロセスの一環で、ユーザーが自分 のデータに対するアプリケーションのアクセスを明示的に承認するステップです。 ユーザーはここで、どの情報を共有するかを選択し、自身のプライバシーをコント ロールする権限を持っています。 
 


もう一度ログインフローを見てみる
 ・Access redirect_uri with state and authorization code
 
 認可コードの取得
 
 ユーザーが承認を完了すると、「 LINEプラットフォーム」は認可コードを発行し、 redirect_uri を通じて「Web app」にこのコードを送信します。これは OAuth 2.0 プロトコルの一部で、ユーザーの明確な同意を受けた上でクライアントアプリケー ションが認可コードを安全に受け取るための手順です。この認可コードは後ほどア クセストークンと交換される重要な中間情報です。 
 


もう一度ログインフローを見てみる
 ・ ✅ Verify that the state sent to the user is the same as the state received from the LINE Platform.
 
 セキュリティ確認
 
 「Web app」は、セキュリティを保つために重要なチェックを行います。ユーザーに リダイレクト時に送った stateが、LINEプラットフォームから受け取った stateと一 致するかを確認します。これにより、ユーザーのセッションが正しいものであること を保証し、偽装サイトなどからの攻撃を防ぐための OAuth 2.0プロトコルに基づい たセキュリティ対策です。 


もう一度ログインフローを見てみる
 ・Request access token / Access token
 
 アクセストークンの要求 
 
 「Web app」は、ユーザーからの認可を受けた証として得られた認可コードを、 「LINEプラットフォーム」に送り、アクセストークンと交換を要求します。アクセストー クンは、ユーザーのデータにアクセスするための「鍵」として機能し、 OAuth 2.0プ ロトコルに従って安全に交付されます。 
 
 アクセストークンと共に、「 Web app」はIDトークンも受け取ります。 IDトークンに は、ユーザーの認証情報を表すクレームが含まれており、安全な方法でユーザー の身元を確認することができます。 OpenID Connectプロトコルは、このIDトーク ンを利用してユーザーの認証情報を「 Web app」に提供し、ユーザーが誰である かを確認するプロセスを強化します。 
 
 
 
 


もう一度ログインフローを見てみる
 ・Request user profile information / User profile information
 
 ユーザープロファイル情報の取得 
 
 「Web app」は、ユーザーから得た許可を示すアクセストークンを利用して、 「LINEプラットフォーム」からユーザーのプロファイル情報を受け取ります。これに より、「Web app」はユーザーの名前や写真などの個人情報を安全に取り扱うこと ができます。アクセストークンは、ユーザーが「 LINEプラットフォーム」上で正しく認 証され、かつ「Web app」へのデータアクセスを許可していることを示しています。 
 


もう一度ログインフローを見てみる
 ・You're logged in! / (Display user profile information)
 
 ログイン完了。プロフィール情報を表示できます。 


どうでしたか👀 少しでも理解が深まっていると嬉しいです！


フロントエンドについてお話ししましょう！
 https://jobs.layerx.co.jp/1bbf1c26a544409d9ed1e1258551277b