APIサーバにおけるトークン認証をdigる / Diggin token authentication on API servers

Transcript

1. APIサーバにおけるトークン認証をdigる 2024.08.31 札幌ITでぃぐでぃぐ会 vol.2 ～API勉強会～ by @oika
2. 自己紹介 Akio Akasaka (@oika) 文系プログラマー C# & TypeScript lover クライアント側の実装が好き セキュリティ系は弱め
3. アジェンダ Token認証とは アクセストークンとJWT リフレッシュトークン方式 トークンのローテーション
4. おことわり） 「認証」と「認可」を厳密に区別せず話す部分があります 認証 (Authentication)：相手が「誰」であるか、ユーザー本人であるか、身元 を確認すること（ID・パスワードや生体情報を使用） 認可 (Authorization)：ユーザーがアクションに対する権限を有しているか確 認すること X のことをいまだに Twitter と呼びます
5. APIの主な認証方式 Basic認証・Digest認証 APIキー認証 トークン認証
6. Basic認証・Digest認証 Basic認証 ユーザー名とパスワードをBase64エンコーディングしたものをリクエストヘ ッダに入れて送る サーバ側でデコードして検証 Base64は暗号化ではないため、簡単にユーザー名・パスワードを復元可能 HTTPS必須 認証状態はブラウザ等にキャッシュされる 明示的なログアウトの仕組みはない Digest認証 Basic認証と流れは同じだが、ランダムな文字列と組み合わせパスワードをハ ッシュ化した状態で送る
7. APIキー認証 事前に発行された強度の高い認証鍵文字列をリクエストに含めて送る キーはリクエストヘッダに含めたり、クエリのパラメータとして &key=xxxxx のように付与させたり キーさえ入手できれば誰でも認証を通過できる
8. トークン認証 期限付きのアクセストークンをリクエストヘッダに含めて送る方式 ⇒今日の話はこれ 標準化された仕様として、OAuth 2.0とBearer token(RFC 6749, RFC 6750)、OpenID Connect Core 1.0 などがある
9. トークン認証の基本
10. OAuth 2.0 サービスのユーザーが、第三者 のアプリケーションに対して、 自分の認証情報（パスワード） を渡すことなく、サービス上の ユーザーデータへのアクセスを 許可するための仕様（RFC 6749） トークン認証実装においても参 照されることが多い
11. アクセストークンとは 認可サーバからクライアントに 対して発行される、期限付きの トークン このトークンをクライアントか らリソースサーバ（APIサーバ） へのリクエストヘッダに乗せて 送ることで、リソースサーバで の認証に使用される
12. アクセストークンの種類 identifier 方式 キーとなる文字列をアクセストークンにし、キーに紐づくユーザーの情報を 認可サーバのDBに保持する リソースサーバで検証する際には、認可サーバへの問い合わせが必要になる self-contain 方式 アクセストークン自体にユーザーIDを内包させる 偽造されていないことの検証が必要 署名付きの JWT 形式が採用されることが多い
13. JWT(JSON Web Token) とは ユーザーIDやトークンの有効期限といった任意の情報を含むJSONをBASE64URLエ ンコードし、秘密鍵を使って署名したもの ※復号可能なので、パスワードのような秘密情報は含めない 公開鍵を使って偽造されていないことの検証ができる アクセストークンとして使用すると、リソースサーバでのトークン検証のた めに毎回DBや認可サーバに問い合わせる必要がなくなる RFC 7519
14. JWT認証の流れを理解する https://qiita.com/asagohan2301/items/cef8bcb969fef9064a5c
15. リフレッシュトークン方式
16. アクセストークン (JWT) の問題点 窃取されると第三者による悪用が可能 不正利用が検知された場合に、強制的に失効させる方法がない ⇒有効期限を短くし、定期的にリフレッシュさせる方法がとられる
17. トークンのリフレッシュ 認可サーバから、アクセストークンと同時にリフレッシュトークン（アクセスト ークン更新のためのトークン）を発行する アクセストークンに比べて、リフレッシュトークンの有効期限を長く（あるいは 無期限に）する アクセストークンの期限が切れた場合、クライアントはリフレッシュトークンを 用いて、認可サーバに対してアクセストークンの更新を要求する
18. +--------+ +---------------+ | |--(A)------- Authorization Grant --------->| | | | | | | |<-(B)----------- Access Token -------------| | | | & Refresh Token | | | | | | | | +----------+ | | | |--(C)---- Access Token ---->| | | | | | | | | | | |<-(D)- Protected Resource --| Resource | | Authorization | | Client | | Server | | Server | | |--(E)---- Access Token ---->| | | | | | | | | | | |<-(F)- Invalid Token Error -| | | | | | +----------+ | | | | | | | |--(G)----------- Refresh Token ----------->| | | | | | | |<-(H)----------- Access Token -------------| | +--------+ & Optional Refresh Token +---------------+ Figure 2: Refreshing an Expired Access Token （RFC 6749 より）
19. リフレッシュトークンの実装 アクセストークンと違って、リフレッシュトークンはJWT形式にはせず、十分な強 度のあるランダムな文字列として、認可サーバのDB等に保持することが多い JWTにすると単独で検証可能なため、サーバ側で強制的に失効させる手段がない 不正アクセス検知時（後述）や、明示的なログアウト時
20. 疑問 アクセストークンの期限を短くすることで、アクセストークンの漏洩に対するセ キュリティリスクを下げることができたが・・ リフレッシュトークン自体が漏洩したらどうするの？ ⇒「OAuth 2.0 Security Best Current Practice」では、リプレイ攻撃検出のため に以下のいずれかの方法を採用せよとある リフレッシュトークンを特定のクライアントに暗号的にバインドする リフレッシュトークンのローテーション を行う
21. リフレッシュトークンのロ ーテーション 認可サーバがアクセストークン のリフレッシュを行う際、リフ レッシュトークン自体も新しい ものを発行し、古いものは（数 秒の猶予時間の後）無効化する 無効化されたリフレッシュトー クンによってアクセストークン のリフレッシュが再要求された 場合、第三者による不正利用が 生じたとみなし、そのリフレッ シュトークンから派生したリフ レッシュトークンを即時無効化 する
22. 4択クイズ 傾向と対策
23. Q. API は何の略？ A. Application Programming Interface REST（Representational State Transfer）もあわせて覚えておくこと
24. Q. 実在する API は？ A. 以下はいずれも実在 米国石油協会 (American Petroleum Institute) 医薬品有効成分 (Active Pharmaceutical Ingredient) 大気汚染指数 (Air Pollution Index) ※マレーシアでは Air Pollutant Index
25. ありがとうございました 参考資料 The OAuth 2.0 Authorization Framework https://datatracker.ietf.org/doc/html/rfc6749 JSON Web Token (JWT) https://datatracker.ietf.org/doc/html/rfc7519 OAuth 2.0 Security Best Current Practice draft-ietf-oauth-security-topics-14 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-14 OAuth & OpenID Connect 関連仕様まとめ https://qiita.com/TakahikoKawasaki/items/185d34814eb9f7ac7ef3 OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る https://qiita.com/TakahikoKawasaki/items/f2a0d25a4f05790b3baa 【第二弾】OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る https://qiita.com/TakahikoKawasaki/items/30fbd546935cea914e4f APIトークン認証の論理設計 https://zenn.dev/ad5/articles/fae2e929fca79e JWT認証の流れを理解する https://qiita.com/asagohan2301/items/cef8bcb969fef9064a5c