REV UP 2021でお話したLINEログインの最近のアップデートとPKCE対応に対応したアプリ連携について紹介します

1. LINEログインの最新アップデートと
アプリ連携ウォークスルー
2021/10/2
富⼠榮 尚寛
@phr_eidentity

2. ⾃⼰紹介
+役割
+ OpenIDファウンデーション・ジャパン代表理事、KYC WGリーダー
+ ⽶国OpenID Foundation eKYC and Identity Assurance WG, co-chair
+書き物など
+ Blog︓IdM実験室（https://idmlab.eidentity.jp）
+ 監訳 : クラウド時代の認証基盤 Azure Active Directory 完全解説
+ 共著 : クラウド環境におけるアイデンティティ管理ガイドライン
+その他活動
+ ⽇本ネットワークセキュリティ協会アイデンティティ管理WG
+ Microsoft MVP for Enterprise Mobility（Jan 2010 -）
+ LINE API Expert （Feb 2018 -）
+ Auth0 Ambassador（Sep 2018 -）
#linedc_revup_A

3. Agenda
+LINE Login アップデート
+Public Client で LINE Login を安全に使うには
+PKCEを中⼼に実装ウォークスルー
+おまけ）FIDO2 Server
#linedc_revup_A

4. LINE Login アップデート
+こちらを追いかけてみる（とりあえず最近の分）
+https://developers.line.biz/ja/news/tags/line-login/
⽇付 アップデート 内容
2021/9/21 ⾃動ログインを無効にする
パラメータの追加
⾃動ログインと SSO の両⽅が使える環境においては⾃動ログイ
ンが優先されるようになったが、disable_auto_login=true を指
定すると明⽰的に SSO のみを利⽤
2021/7/12 SSO より ⾃動ログインが
優先される
⾃動ログインと SSO の両⽅が使える環境においては⾃動ログイ
ンが優先されるようになった
2021/6/15 MID → ユーザIDへの変換
API の提供終了
v1 で使っていた MID を v2 へ移⾏する際の変換時に必要な API
の提供が終了
2021/5/12 アサーション署名キーの発
⾏⼿順の変更
鍵ペアの⽣成を LINE サーバ側ではなくローカルで実⾏するよう
に変更
2021/4/9 PKCE 対応 RFC 7636 PKCE に対応。Yahoo! JAPAN アプリからのアクセス
が⾃動ログインに対応
#linedc_revup_A

5. 注⽬の⼀つが PKCE 対応
+PKCE（RFC 7636）※ぴくしー
+https://datatracker.ietf.org/doc/html/rfc7636
+Proof Key for Code Exchange by OAuth Public Clients
+認可コードの横取り攻撃を防ぐための仕組み
#linedc_revup_A

6. OAuth2.0 の基本︓認可コードフロー
#linedc_revup_A

7. OAuth2.0 の基本︓認可コードフロー
認可コードをアクセストークンに交換する
際にクライアント認証を⾏う
（通常、client_id/client_secretの利⽤）
→認可コードを横取りされるとアクセス
トークンの取得ができてしまうため
#linedc_revup_A

8. ⼤前提
+Client = アプリケーションの認証を⾏うための情報
（client_id、client_secret）を安全に保存できること
+サーバーサイドで動くアプリケーションなら保護できる
+クライアントサイドで動くパブリッククライアントの場合は︖
+ネイティブアプリ、SPAなど
+特にネイティブアプリだと同⼀カスタムURIスキームの指定で認可
コードを容易に横取り可能
+バックエンドサーバとの組み合わせで回避してきた
#linedc_revup_A

9. OAuth2.0 の基本︓Implicit フロー
#linedc_revup_A

10. OAuth2.0 の基本︓Implicit フロー
アクセストークンを直接取得、UA
上で動作するJS等でfragmentから
取り出してクライアントへ送信する
#linedc_revup_A

11. セキュリティ上の問題
+RFC 6749 セキュリティ上の考慮事項
+10.16. インプリシットフローにおけるリソースオーナーなりすま
しのためのアクセストークン不正利⽤
インプリシットフローを利⽤するパブリッククライアントについて, この仕様はアクセストークンがどのクライアントに発⾏されたかを特定する⽅法をクライアント
に提供しない.
リソースオーナーは攻撃者の悪意のあるクライアントにアクセストークンを許可することにより, 進んでリソースへのアクセスを委任するかもしれない. これは
フィッシングまたは何か他の詐欺が原因となるかもしれない. 攻撃者はまた, なんらかのメカニズムでトークンを盗むかもしれない. それから, 攻撃者は正当なパブ
リッククライアントへのアクセストークンを提供することでリソースオーナーへのなりすましを試みるかもしれない.
インプリシットフロー (response_type=token) では, 攻撃者は認可サーバーからのレスポンスに含まれるトークンを簡単に変更し, 以前攻撃者⾃⾝に発⾏された実
際のアクセストークンに置き換えることができる.
アクセストークンを差し込める信⽤できないアプリケーションを作成する攻撃者により, クライアントのユーザーを特定するためにネイティブアプリケーションと通
信しバックチャネルでアクセストークンを受け取っているサーバーは同様の危険性を持つ.
リソースオーナーだけがそのリソースに対する有効なアクセストークンを提⽰できると仮定されるいかなるパブリッククライアントも, このタイプの攻撃に対して脆
弱である.
このタイプの攻撃は正当なクライアントでリソースオーナーの情報を攻撃者 (悪意のあるクライアント) に公開するかもしれない. これはまた, 合法なクライアントに
て攻撃者にもともとアクセストークンもしくは認可コードを与えられたリソースオーナーと同等の資格で活動することを許可する.
クライアントへのリソースオーナー認証⽅法はこの仕様の範囲外である. ユーザー認証をクライアント (3rdパーティーサインインサービスなど) に委任する認可プロ
セスを使⽤するどんな仕様でも, アクセストークンがその使⽤のために発⾏されたかどうか特定するためのセキュリティメカニズム (オーディエンス制限のあるアク
セストークン) の追加なしにインプリシットフローを利⽤してはならない (MUST NOT).
#linedc_revup_A

12. セキュリティ上の問題
+RFC 6749 セキュリティ上の考慮事項
+10.16. インプリシットフローにおけるリソースオーナーなりすま
しのためのアクセストークン不正利⽤
インプリシットフローを利⽤するパブリッククライアントについて, この仕様はアクセストークンがどのクライアントに発⾏されたかを特定する⽅法をクライアント
に提供しない.
リソースオーナーは攻撃者の悪意のあるクライアントにアクセストークンを許可することにより, 進んでリソースへのアクセスを委任するかもしれない. これは
フィッシングまたは何か他の詐欺が原因となるかもしれない. 攻撃者はまた, なんらかのメカニズムでトークンを盗むかもしれない. それから, 攻撃者は正当なパブ
リッククライアントへのアクセストークンを提供することでリソースオーナーへのなりすましを試みるかもしれない.
インプリシットフロー (response_type=token) では, 攻撃者は認可サーバーからのレスポンスに含まれるトークンを簡単に変更し, 以前攻撃者⾃⾝に発⾏された実
際のアクセストークンに置き換えることができる.
アクセストークンを差し込める信⽤できないアプリケーションを作成する攻撃者により, クライアントのユーザーを特定するためにネイティブアプリケーションと通
信しバックチャネルでアクセストークンを受け取っているサーバーは同様の危険性を持つ.
リソースオーナーだけがそのリソースに対する有効なアクセストークンを提⽰できると仮定されるいかなるパブリッククライアントも, このタイプの攻撃に対して脆
弱である.
このタイプの攻撃は正当なクライアントでリソースオーナーの情報を攻撃者 (悪意のあるクライアント) に公開するかもしれない. これはまた, 合法なクライアントに
て攻撃者にもともとアクセストークンもしくは認可コードを与えられたリソースオーナーと同等の資格で活動することを許可する.
クライアントへのリソースオーナー認証⽅法はこの仕様の範囲外である. ユーザー認証をクライアント (3rdパーティーサインインサービスなど) に委任する認可プロ
セスを使⽤するどんな仕様でも, アクセストークンがその使⽤のために発⾏されたかどうか特定するためのセキュリティメカニズム (オーディエンス制限のあるアク
セストークン) の追加なしにインプリシットフローを利⽤してはならない (MUST NOT).
要は、できれば使うな、と
#linedc_revup_A

13. となると
+クライアント認証＝意図したクライアントに対してのみアク
セストークンを発⾏することができる仕組みが必要
+Proof Key for Code Exchange by OAuth Public Clients
+以下のクライアントが⼀致することを証明するための仕組み
+認可コードを持ってくるクライアント
+認可サーバが元々認可コードを発⾏したクライアント
#linedc_revup_A

14. 認可コードフロー＋PKCE
Code_verifierの
⽣成・保持
Code_challenge/
methodの⽣成、
送信
Code_challenge/
methodの保存と
認可コード発⾏
code_verifierと保持し
ておいた
code_challengeで検証
認可コードと
code_verifierの
送信
#linedc_revup_A

15. 超シンプルな JS App を作ってみる
<button id="startButton">Start OAuth Flow</button>
<scritp>
document.getElementById("startButton").onclick =
function() {
// code_verifierの⽣成
var codeVerifier = generateRandomString(64);
参考コード
https://github.com/curityio/pkce-javascript-example
#linedc_revup_A

16. code_verifierの⽣成（ランダム⽂字列）
function generateRandomString(length) {
var possible = "ABCDEFGHIJ…456789";
for (var i = 0; i < length; i++) {
text += possible.charAt(Math.floor(Math.random()
* possible.length));
}
return text;
}
43⽂字〜128⽂字のURL safeな⽂字列
[A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~"
#linedc_revup_A

17. code_challengeの⽣成
（method:S256の場合）
async function generateCodeChallenge(codeVerifier) {
var digest = await crypto.subtle.digest("SHA-256",
new TextEncoder().encode(codeVerifier));
return btoa(String.fromCharCode(...new
Uint8Array(digest))).replace(/=/g, '').replace(/¥+/g, '-
').replace(/¥//g, '_')
}
code_challenge = BASE64URL-
ENCODE(SHA256(ASCII(code_verifier)))
#linedc_revup_A

18. セッションにcode_verifierを保存して
認可サーバへリダイレクト
generateCodeChallenge(codeVerifier).then(function(codeChallenge)
{
window.sessionStorage.setItem("code_verifier", codeVerifier);
var redirectUri = window.location.href.split('?')[0];
var args = new URLSearchParams({
client_idなど,
code_challenge_method: "S256",
code_challenge: codeChallenge});
window.location = authorizeEndpoint + "/?" + args;
#linedc_revup_A

19. 認可コードを受け取り、code_verifier
と⼀緒に認可サーバへ送信
xhr.open("POST", tokenEndpoint, true);
xhr.send(new URLSearchParams({
client_id: clientId,
code_verifier: window.sessionStorage.getItem("code_verifier"),
grant_type: "authorization_code",
redirect_uri: location.href.replace(location.search, ʼʼ),
code: code
}));
#linedc_revup_A

20. id_tokenの受け取り
if (xhr.status == 200) {
message = "Hello "+decodeJwt(response.id_token).name;
}
※scopeにopenidを指定したので、id_tokenを受け取って名前を表⽰
#linedc_revup_A

21. 動かしてみる Codeはこちら
https://github.com/fujie/memo/blob/main/withpkce_pub.html
#linedc_revup_A

22. Yahoo!JAPANアプリでの挙動
PKCEを無効にすると
このボタンを押しても
反応しなくなる
#linedc_revup_A

23. おまけ）FIDOサーバー
+2021/8/5 ついに公開されました。
+https://github.com/line/line-fido2-server
+⾃社サービスに FIDO を使ったパスワードレス認証を組み込
みたい⼈はぜひ参考にしてみると良いと思います。
+ファーストタッチを blog に書いたのでこちらで。
+https://idmlab.eidentity.jp/2021/08/linefido2oss.html
+もっと深く触った結果はまとまり次第書こうかと。
+ちなみにFIDO Japan WG の副座⻑は LINE の市原さん
#linedc_revup_A

24. まとめ
+LINE ログイン、⽇々アップデートされてます
+安全にアプリ実装をするために必要な仕様にも対応して⾏っ
ていますので、キャッチアップしていきましょう
+パスワードレスで強度の⾼い認証機構である FIDO にも
LINE は取り組んでいるので⾃社サイトにもどんどん取り込
んでいきましょう
#linedc_revup_A