[レポート] 実装して理解するLINE LoginとOpenID Connect入門 に参加してOAuthとOpenID Connectについても学んできた #linedc

こんにちは、Mr.Moです。

LINE Loginをテーマに「OAuth」、「OpenID Connect」についても解説される勉強会に参加させていただきました。 さっそく簡単にまとめたいと思います。

概要

OAuth や OpenID Connect などアイデンティティや認証に関するテクノロジーは座学だけでは理解するのが中々難しい分野なので、LINE Login でログインする簡単な Web アプリを実際に作ってみることで、動きを理解できるようにしていきます。

https://linedevelopercommunity.connpass.com/event/121596/

当日の資料は下記にアップしていただいてます！ https://www.slideshare.net/naohiro.fujie/line-loginopenid-connect

抑えておきたいキーワード

先に「認可」と「認証」というキーワードを抑えておきます。 似て非なるものだということを理解しておきましょう。 （Wikipediaの文章も引用しつつ書いていきます。）

認可

認可とは？

情報セキュリティおよびコンピュータセキュリティに関わるリソースへの、とりわけアクセス制御へのアクセス権限を特定する機能である。

例えばとあるリソースがあったとして、そのリソースにアクセスする権限を特定する機能。（対象が何者であるかといったことは範疇ではない）

認証

認証とは？

何かによって、対象の正当性を確認する行為を指す。

要するに対象が何者であるかという点にフォーカスして確認するということ。

OpenID Connectとは

上記スライドの「OpenID Connectとは」を語る上で、「OAuth」や「アイデンティティレイヤー」というキーワードを先に理解しておく必要がありますので順番に見ていきます。

OAuth2.0とは

• サードパーティアプリケーション
• HTTPサービス
• 限定的なアクセス
• 可能にする

上記のキーワードを具体的な例に当てはめると下記のようになります。

• サードパーティアプリケーション：OAuthクライアント、自分が開発したアプリケーションなど
• HTTPサービス：リソースサーバ、Google Calendar API
• 限定的なアクセス：スコープ、Calendar情報読み取り
• 可能にする：認可サーバ、Google Account(サーバ)

OAuth2.0は上記で上げたキーワードの内、「認可」の役割が該当します。資料の例で言うと「Google Account(認可サーバ)」に問い合わせてアクセストークンを取得し、そのアクセストークンを使って「Google Calendar API(リソースサーバ)」にアクセスできている流れの部分です。

OAuth2.0では上記のような「権限の認可」を実質の標準規格として定めています。また、「権限の認可」を実現するのに用いられているのが「アクセストークン」です。 なお、「アクセストークン」により一時的なリソースへのアクセスは実現されますが、アクセスしてきた対象が何者であるかまでは確認できない点に注意が必要です。

上記のスライドに記載がある通りアクセストークンは無記名式の切符とも言えるようなもので、アクセスしてきた対象が何者であるかを特定する情報は含まれていないランダムな値です。にもかかわらず認証と誤解されるのはアクセストークンの取得で認可サーバに問い合わせる際にログインの行為を行うため、OAuthが認証として使えると誤用されてしまうようです。

誤用①

上記スライドは、アクセストークン発行するためのログインを認証のログインとして勘違いしてしまっている例です。

誤用②

上記スライドでは、アクセストークンによりプロファイル情報が取得できたことで認証できた(対象が何者であるか特定できている)と勘違いしてしまっている例です。

アクセストークンは誰のものかまでは検証できないため認証には全く使えないものです。OAuthを「認証/ID連携/シングルサインオン」といった用途に使うべきでないということが言えますね。

アイデンティティレイヤーとは

認証では、アクセスしてきた対象が何者であるかを検証できなければなりません。それを実現するのがアイデンティティレイヤーです。アイデンティティレイヤーは「ID Token」と「User Infoエンドポイント」で構成されています。

ID Token

JWT形式(ジョットと読む)でペイロードの中に明示的に名前も入ってる。最終的にはBase64Urlエンコードされ、頭に「eyJ」がつくのが特徴。

ちなみに下記のサービスでBase64UrlされたJWT形式の値をデコードできるので便利。

• jwt.ms
• jwt.io

User Infoエンドポイント

ユーザ情報を取得する方法の標準化。ID Tokenにも名前などの情報が入っており、ユーザ情報の取得としても使えなくもないが効率などの面からユーザ情報の取得はUser Infoエンドポイントで行うという方針になっている。

OpenID Connectとは

ここまでを踏まえて、冒頭の「OAuth 2.0 プロトコルの上にシンプル なアイデンティティレイヤーを付与したものである」という説明がイメージできOpenID Connectへの理解が進んだと思います。 上記のスライドはOAuthとOpenID Connectの違いを示した表です。上記のスライドから「認証/ID連携/シングルサインオン」といった用途にはこの「OpenID Connect」を使うのが適切ということになります。

LINE のid_tokenの中身

OpenID Connectの理解が進んだところで早速今回のテーマであるLINEのid_tokenの中身を見ていきます。 上記のスライドの情報から、実際の処理では上からiss～nonceまでの項目の値をチェックしてid_tokenが問題無いか、対象が何者であるかをチェックする実装が良さそうです。（Authで利用するアクセストークンのようなランダム値だけでは、こういったチェックはできないですね）

LINE Loginの実装コードを見てみる

LINE Loginの実装コードを用意していただいてます！（下記のコードは講義用のためOpenID Connect処理フローが途中で止まるようにしていただいてます） https://github.com/fujie/line_login

上記のコードは手元で動かすことも可能になっています。詳しくはREADMEをご覧ください。実際に動いているところを見るとさらに理解が進むと思います！

まとめ

今回の会は非常に内容が濃い素晴らしいものでした。正直本記事では全てをまとめきれていません 笑（再演が待たれますね！) LINE Loginの理解が深まりましたので今後スキあらば活用していきたいと思っています！