Share
Embed
LINEログインのログインフローを理解して使う
minako-ph
November 10, 2023
Transcript
46 slides
-
もう一度ログインフローを見てみる 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の認可コードの付与のフローとは(LINEプラットフォームの例) 1. ユーザーのリダイレクト 2. ユーザー認証 あなたの情報をLINEから貰いたいから ログインしてきてやー おっけー ログインっと。
おー。メアドもパスワードも合って る。本当にこのユーザーは言ってい る通りの人物だ。 -
OAuth 2.0の認可コードの付与のフローとは(LINEプラットフォームの例) 3. アクセス承認 4. 認可コードの取得 チケットアプリにあなたの名前とメールア ドレスを渡してもいい? いいよ〜 お、LINEから「秘密の合言葉」を貰えた。これ
が認可コードか。これを使ってユーザー情報 の取得ができそうだ -
OAuth 2.0の認可コードの付与のフローとは(LINEプラットフォームの例) ・主なフローのステップ 1. ユーザーのリダイレクト : クライアントアプリケーションはユーザーを LINEのログインページへリダイレクト
し、認証を要求します。 2. ユーザー認証: ユーザーはLINEアカウントでログインし、自分の身元を確認します。 3. アクセス承認: LINEの認可画面でユーザーはクライアントアプリケーションが特定の情報にアクセスする ことを承認します。 4. 認可コードの取得: 承認後、LINEプラットフォームはクライアントアプリケーションに認可コードを発行しま す。 5. アクセストークンの交換 : クライアントアプリケーションは認可コードを LINEプラットフォームに送信し、アク セストークンと交換します。 6. リソースへのアクセス : アクセストークンを使用して、クライアントアプリケーションは LINEプラットフォーム 上でユーザーのデータにアクセスします。 -
OAuth 2.0の認可コードの付与のフローとは(LINEプラットフォームの例) ・ポイント • 間接的なトークン配布 : ユーザーの認証情報は第三者アプリに直接渡され ず、一時的な認可コードを介して間接的にアクセストークンが交換されるた
め、情報漏洩のリスクが減少します。 • 限定的なアクセス: アクセストークンはユーザーが承認した情報や機能へのア クセスのみを提供し、全てのユーザーデータへのアクセスを許可しないため、 ユーザーのプライバシーを保護します。 • 短命の認可コード: 認可コードは短期間で失効するため、仮に盗まれたとして も安全性が保たれます。 • ユーザーは安心して第三者アプリを利用でき、サービス提供者は信頼性を高 めることができます。 -
OpenID Connect プロトコルとは(LINEプラットフォームの例) 2. IDトークンの発行 Aさんが正しくログインし、情報共有に同意し たことを確認したので、 IDトークンを発行しま す〜
IDトークンをチェックした結果、 Aさんがログ インしていることがわかったぞ 3. ユーザー情報の取得 -
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の認可フレームワークに認証の安全性を強化します。 -
もう一度ログインフローを見てみる ・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)
ログイン完了。プロフィール情報を表示できます。