DjangoとFastAPIによる 実践認証技術

Transcript

1. Django とFastAPI による 実践認証技術 PyCon JP 2024/9/28 Recustomer株式会社 @shimakaze_soft
2. お前、誰よ • 名前 ◦ 大島和輝 (X:@shimakaze_soft) ◦ 社内では「しまかぜ」と呼ばれている • Recustomer株式会社 ◦ バックエンドエンジニア ◦ データエンジニア • 趣味 ◦ サッカー ◦ 歴史
3. Recustomer について
5. 目次 • 本トークを話そうと思ったきっかけ • 認証の基本概念 • ステートレス vs ステートフル認証 • Djangoにおける認証技術 • FastAPIにおける認証技術 • 実際の適用例とベストプラクティス • まとめ
6. 本トークを話そうと思ったきっかけ
7. 近年のモダンな WEBアプリケーションの構成 • フロントエンドとバックエンドを完全に 分離するような構成が当たり前になっ てきている • フロントエンドはReactなどのSPAの構 成にして、バックエンドはWebAPIのみ を提供する構成 BackEnd WebAPI FrontEnd HTTP Request
8. full-stack frameworkでの 開発は最初は楽で便利
9. フルスタックフレームワークでの開発 • full-stack frameworkはテストから ORMとマイグレーションからフロント、 バックエンドとこれ一つあればWEBア プリケーションの開発ができるあらゆ る機能を提供している • 認証などの機能も何も考えず実装で きる full-stack framework full-stack framework
10. full-stack frameworkでの 開発の問題点
11. full-stack framework での開発の問題点 • フロントエンドの開発もできる分、元々 組み込まれているテンプレート機能を 使って最初は開発をしがちである full-stack framework full-stack framework
12. full-stack framework での開発の問題点 • Djangoであれば、フロントエンドのテ ンプレート機能としてDjango Templateを提供している • Laravelであれば、Bladeテンプレート というものがある • バックエンドもフロントエンドもあらゆる 機能を提供している分、スケーラビリ ティや開発生産性の低下などの後々 の開発に影響を与えていく 事が多い full-stack framework full-stack framework
13. フロントエンドとバックエンドが 密結合になりがち
14. フロントエンドとバックエンドが 密結合になりがち • 最初の開発は楽でも、開発が進んで いくごとにバックエンドとフロントエンド が別々で開発がし辛くなる • 近年のReactやVueといったモダンな フロントエンドの技術(Scss, webpack など)が使いづらくなる full-stack framework full-stack framework
15. モダンなWeb開発ではフルスタックフレームワークの Template 機能を使 わず、 フロント（表示）の部分は React やVueに任せて、 Web API サーバーとして使うのが現在では主流である
16. フルスタックからこの構成を目指していく • Djangoなどのフルスタックフレーム ワークではWebAPIのみを提供して、 フロントエンド部分はReactで表示させ るようにする BackEnd WebAPI FrontEnd HTTP Request
17. ここで一つ浮かぶ疑問
18. ここで一つ浮かぶ疑問 • Djangoなどをfull-stack frameworkと して使っていれば、普通にフロントエン ドのテンプレートとviews.py(バックエ ンド側のAPI)を実装して認証の機能 を今までは簡単に実現できていた BackEnd WebAPI FrontEnd HTTP Request
19. SPA(React, Vue) + WebAPIの構成にした時に 認証の機構はどう実現すれば良いのか
20. 本トークのきっかけと目的 • Ruby(Rails), PHP(Laravel)などでは このようなモダン構成のノウハウや資 料はネットにたくさんあっても、Python では資料が少ないと感じていた • 本トークではSPA + WebAPI(Django, FastAPI)の構成にしたときの実践的 な実装方法について主に話していく BackEnd WebAPI FrontEnd HTTP Request
21. 本日お話ししないこと • OAuthなどについては話さない • 認証については扱うものの認可については深掘りしない • DjangoとFastAPIの基本的なエンドポイントの作成の仕方 • 一部、ORMの話が出てくるが詳細は語らない
22. 本日お話しすること • 一般的なログイン認証（メールアドレスとパスワードによる）に焦点を当てる • 従来的のセッション認証やトークンベースのJWT（JSON Web Token）などを利用し た認証の実装方法について • DjangoやFastAPIなどのWebAPIでの実装方法 • 認証トークンの保持の仕方
23. 認証の基本概念
24. 認証（Authentication ）とは何か • 認証は、システムへのアクセスを許可する前に、ユーザーの身元を確認するプロ セスのこと。 • 認証中、ユーザーは通常ユーザー名である身元確認の形式を提供し、自分が何者 かを証明する。 彼らは、パスワード、トークン、生体認証などで身元を証明する。
25. 認可（Authorization ）とは何か • 認可は、システムリソースに対するユーザーのアクセスレベルを決定するプロセス。 • 認可後、システムは特定のリソースに対する許可されたユーザーのアクセスレベルを決定 する。 • ex. 書籍管理システムを例にとる ◦ 一般従業員は書籍情報の作成と読み取り権限はあっても、編集と削除を行う権限がない ◦ マネージャーは編集と削除権限があるなど • 認証と認可は異なるプロセスだが、密接に関係している • まず認証を行ってから、次に認可を行う
26. 認証と認可の違い 認証 • 「誰があなたですか？」 • システムへのアクセスを許可する前に、ユー ザーの身元を確認する 認可 • 「何ができますか？」 • 認可は、システムリソースに対するユー ザーのアクセスレベルを決定する
27. 冒頭でも述べた通り、認可についての設計などに ついてはお話ししません
28. ステートフルとステートレス認証
29. ステートフル認証 • サーバー側に状態を保持する ◦ ユーザーがログインすると、サーバーがセッション IDを発行し、セッションの状態をサーバー側で管 理する。 ◦ セッション情報はサーバーのメモリやデータベースに保存され、ユーザーが再度リクエストを送る際 に、このセッションIDを使用して認証を行う。 • 基本的にセッション IDを使用 ◦ クライアントはセッション IDをクッキーなどに保存し、 HTTPリクエストごとにサーバーへ送信する。 サーバーはこのセッション IDを参照し、ユーザーの状態を確認する。 • 大体のWEBフレームワークで実装するとデフォルトではステートフル認証になることが多い（　 Django, Rails, Laravelなど）
30. ステートフル認証 BackEnd WebAPI FrontEnd • バックエンドがログイン状態を管理し ており、ログインしているアカウントを 把握している • 門番が門を入って中に入った人と出 ていった人の台帳を持って記録してい るのと似ている DB 状態を管理
31. ステートレス認証 • サーバー側に状態を保持しない ◦ ステートレス認証では、サーバーがクライアントの状態を保持せず、すべてのリクエストが独立して 処理される。 ◦ ユーザーが認証された際に発行されるトークンには、ユーザー情報や認証状態が含まれており、 サーバー側で認証状態を保持する必要がない。 • 基本的にはトークンを使用 ◦ クライアントはトークンをヘッダーなどに添付してサーバーに対してリクエストして、 サーバーはトー クンの有効性を検証する ことで認証を行う。 ◦ サーバーはトークン有効性を検証するのみで、 クライアントの状態を保持しない 。 • SPA + Web APIの構成を取る際に使用される事が多く、トークンには JWTを使用する事が多い。
32. ステートレス認証 BackEnd WebAPI FrontEnd • バックエンドがログイン状態を管理し ていない • 門番が一度通行手形を与えたら、期 限内であれば自由に門を出入りでき るのと一緒
33. 両者の違いと比較
34. セッション認証とトークン認証
35. セッション認証 • セッション認証は、ユーザーがログインするとサーバー側でセッションを作成し、 ユーザーにセッションIDを発行する。 • セッションの管理には通常、セッションIDが使われる。セッションIDは、サーバーが 生成する一意な識別子で、クライアントに対して発行されます。このセッションIDを 使って、サーバーはどのリクエストがどのユーザーに関連するかを追跡する。 • このセッションIDはCookieに保存され、以後のリクエストにおいてクライアントから サーバーに送信されます。 • サーバーはセッションIDを元にユーザー情報を管理する。
36. トークン認証 • トークン認証は、認証が成功した際にサーバーがユーザーにトークン（一般的には JWT: JSON Web Tokenなど）を発行する。 • このトークンはユーザーが保持し、以後のリクエストにおいてHTTPヘッダーに付与 してサーバーに送信されます。サーバーはトークンを検証し、ユーザーの認証状態 を確認する。
37. JWTとは • JWT (JSON Web Token) は、ユーザー認証や情報の安全な交換に用いられるコ ンパクトでURLセーフなトークン形式の文字列。 • 主にWebアプリケーションやAPIで広く使われており、認証情報やその他の情報を クライアントとサーバー間で安全にやり取りするために使用されます。 • JWTは、以下の3つの部分で構成されている。 ◦ ヘッダー (Header) ◦ ペイロード (Payload) ◦ 署名 (Signature)
38. JWTとは • JWTはこれらの部分をドット (.) で区切って一つの文字列として表現され、エンコー ドされてクライアントに渡されます。 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZ SI6IkpvZSIsImlhdCI6MTUxNjIzOTAyMn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6 yJV_adQssw5c 赤がヘッダー、ペイロードが青、緑が署名部
39. JWT (Header) • トークンの種類（JWT）と使用される署 名アルゴリズム（例: HMAC SHA256 やRSAなど）が含まれている。 • ヘッダーは、JSON形式のオブジェクト として記述され、Base64URLエンコー ドされる
40. JWT (Header) • トークンの種類（JWT）と使用される署 名アルゴリズム（例: HMAC SHA256 やRSAなど）が含まれている。 • ヘッダーは、JSON形式のオブジェクト として記述され、Base64URLエンコー ドされる
41. JWT (Signature) • JWTの署名部分は、ヘッダー、ペイロード、秘密鍵を使って生成される。これにより、 トークンが改ざんされていないことを確認できます。
42. セッション認証とトークン認証
43. 必ずしもステートレス = トークンではない • トークン認証は、ステートレス認証の一例としてよく使われる手法ではある。 • しかし、ステートレス認証は必ずしもトークンに限定されるわけではありません。 • 他の形式のステートレス認証方法も存在する可能性があります。つまり、ステートレ ス認証は「サーバーが状態を保持しない」という概念を指し、トークンはその実現方 法の一つに過ぎない。
44. トークン管理とセキュリティ考慮事項
45. トークンをどこに保持するべきか • トークン認証にした場合、よくこの手の認証系の話だと必ず出てくる • LocalStorageかCookieに保持するべきかで必ず議論が分かれる
46. トークンをどこに保持するべきか • LocalStorage ◦ 利点 ▪ ブラウザのJavaScriptから簡単にアクセスでき、読み書きも容易。 ▪ また、リクエストごとにサーバーに自動送信されないため、 APIエンドポイントごとに必要なとき にヘッダーにJWTをセットして送信するなど、制御がしやすい。 ◦ リスク ▪ 懸念は、XSS（クロスサイトスクリプティング）攻撃です。悪意のあるスクリプトがサイトに注入 されると、ローカルストレージ内の JWTが盗まれるリスクがある。
47. トークンをどこに保持するべきか • Cookie (HttpOnly) ◦ 利点 ▪ クッキーにJWTを保持し、かつHTTP-Only属性を付与することで、 JavaScriptからアクセスで きないようにし、XSS攻撃からJWTを守ることができます。また、クッキーには Secure属性を 付け、HTTPS通信時のみ送信されるように設定することも重要です。これにより、 CSRF（クロ スサイトリクエストフォージェリ）攻撃に対する防御も強化されます。 ◦ リスク ▪ Cookieはリクエストごとに自動で送信されるため、トークンの制御が難しく、 CSRF対策を追加 で行う必要がある。 Djangoも含めた大体のframeworkはデフォルトはSessionのCookie(HttpOnly)を使用している
48. 色々なやり方があるもののここでは Cookie(HttpOnly) で保持していくやり方を 前提に具体的な手法は後述していく
49. 認証で重要な Cookieが持つ基本的な属性 • Domain ◦ Cookieが送信される対象のドメイン。このドメインに対してのみ Cookieが送信される。 • Secure ◦ この属性が設定されている場合、 CookieはHTTPS接続時にのみ送信される。 TrueかFalseで設定 する • HttpOnly ◦ 真偽値型(True: False) ◦ JavaScriptからアクセスできないようにする属性。この属性を設定することで、 XSS（クロスサイトス クリプティング）攻撃を防ぐことができます。 TrueかFalseで設定する • SameSite ◦ クロスサイトリクエスト時に Cookieが送信されるかどうかを制御する属性。 Strict、Lax、Noneの3つ の値があります。 ◦ 詳細は後述します。
50. Django における認証技術
51. Djangoのデフォルトの認証 • Djangoのデフォルト認証機構 • セッションベースの認証 • Djangoには、ユーザー認証と権限管理のための機構がデフォルトで組み込まれて いる • `django.contrib.auth`モジュールを利用して、ユーザー認証、ログイン/ログアウ ト、パスワード管理を簡単に実装可能である
52. Djangoのデフォルトの認証の流れ 1. ユーザーがログインすると、サーバーがセッションIDを生成 2. セッションIDがCookie(HttpOnly)に保存され、リクエストごとにサーバーへ 送信される 3. サーバーはセッションIDを使用して、ユーザーの認証状態を確認
53. Djangoのデフォルトの認証の流れ
54. Djangoのデフォルト認証のメリットとデメリット • メリット ◦ シンプルな実装で認証を構築でき、特にカスタマイズの必要がない場合は便利 ◦ セッション管理やユーザー認証に関する機能がすべて標準で提供されている • デメリット ◦ APIベースの認証や、フロントエンドとバックエンドが分離している構成では非効率 ◦ セッションの管理が必要であり、スケーラビリティが課題になることがある
55. これらをSPA + WebAPI の構成にしていく
56. デフォルトの Djangoで SPA + WebAPIの構成になっていない • デフォルトだとDjango Templateを前提としており、セッションIDなどがDjango Templateのフロントエンドでしか保持できない。 • SPA + WebAPIの構成したい時にはどうすれば良いか
57. django-ninja やdjango-restframework での トークンベース認証
58. django-ninjaやdjango-restframeworkでのトークンベース認証 • サードパーティーライブラリを使わなくてもDjangoにWebAPIだ けの提供をする実装ではできる • サードパーティーライブラリを使った方が簡単に実装できるし、 保守・運用の管理もしやすい
59. django-ninjaとdjango-restframeworkの違い • django-restframework ◦ より機能が豊富で、API開発に必要な多くの機能を提供 ◦ Djangoの認証システムやパーミッション設定などを強力にサポート ◦ DjangoでRESTfulAPIを実装する際に昔からの選択肢になりやすく資料が豊富 • django-ninja ◦ 最近出てきたFastAPIライクな実装ができる、パフォーマンス重視の軽量な APIライブラリ ◦ Pythonの型ヒントを活用し、型安全な開発を実現 ◦ 宣言的でシンプルな設計により、学習コストが低い ◦ 詳細は以下のトークを参考に ▪ Django Ninjaで高速なAPI開発を実現する ▪ 実践ガイドとベストプラクティス 加藤雅也 ▪ 09/27 11:40 - 11:55 (Asia/Tokyo) 20F #pyconjp_1
60. django-restframework でのトークン認証
61. TokenAuthentication • django-restframeworkに標準で入っ ている • ランダムな文字列のトークンを発行し てくれる • auth_tokenというテーブルが作られ、 トークンを格納する • このテーブルが外部キーとしてusers テーブルと紐づく
62. TokenAuthentication • `pip install djangorestframework`で導入が可能 • settings.pyにあるINSTALLED_APPSに以下を加える
63. TokenAuthentication • settings.pyにREST_FRAMEWORKという設定値を作り、以下を加える INSTALLED_APPSに加えれば準 備完了 • models.py内に以下を記述して、 Userのpost_saveシグナルをキャッチして Tokenを追加する
64. TokenAuthentication • views.pyを右のように少しカスタマイズする • response.set_cookieにしてcookieを httponly=Trueにするようにして、レスポンス を返す ◦ httponly=Trueにすることでjsからのアクセス をさせないようにして、xssの対策を施す
65. django-ninja でのJWT認証
66. django-ninjaでのJWT実装 • django-restframeworkはトークンを生成できる機構があったが、django-ninjaは 自前で実装しなければいけないところが多い • jwt部分の生成も検証も自前で実装しなければいけない分、django-ninja自体がシ ンプルな実装でカスタマイズもしやすい
67. django-ninjaでのJWT実装 • `pip install django-ninja pyjwt`を導入する ◦ django-ninja ◦ pyjwt • settings.pyを作成して、いくつかの変数を用意する
68. django-ninjaでのJWT実装 • JWTトークンの生成と検証を行うため の関数を実装する • これにより、ユーザー認証時にトーク ンを発行し、後続のリクエストでトーク ンの検証を行う
69. django-ninjaでのJWT実装（ログイン時） • emailとpasswordからユーザー情報 をまず取り出し、先ほど作成した create_jwt_token関数でトークンを生 成する • ユーザーがログインし、JWTトークン をHttpOnly=TrueのCookieとして返す エンドポイントを作成
70. django-ninjaでのJWT実装（JWTの検証） • JWTトークンをクッキーから取得して 認証するためのカスタム認証クラスを 作成する。 • このクラスはリクエストに含まれるクッ キーからトークンを取得し、そのトーク ンを検証する。
71. django-ninjaでのJWT実装（JWTの検証） • 認証が必要なエンドポイントでは、リク エストのクッキーからJWTトークンを読 み取って認証を行う • 先ほど作成した JWTAuthFromCookieをデコレータに 付与する
72. FastAPI における認証技術
73. FastAPIでのJWT実装 • FastAPIはそもそもがWebAPIを提供することを前提に作られたシンプルなフレーム ワークであるため、django-ninja同様に全て自前で実装しなければいけない • ここでは以下を使用する ◦ ORMとしてよくある組み合わせとして使われる SQLAlchemだが、ORMの説明が長くなるため省く ◦ jwtの生成にはpython-joseを使用する
74. FastAPIでのJWT実装 • `pip install fastapi python-jose`を導入する ◦ fastapi ◦ python-jose
75. FastAPIでのJWT実装 • JWTトークンの生成と検証のために、 python-joseでJWTのエンコードとデ コードの関数を作成
76. FastAPIでのJWT実装 • ユーザーがログインすると、JWTトー クンを生成してレスポンスの set_cookieで返す
77. FastAPIでのJWT実装 • 認証が必要なエンドポイントでは、リク エストのクッキーに含まれるJWTトー クンを取り出し、検証する
78. 実際の適用例とベストプラクティス
79. CookieでHttpOnlyは必ず付与する • HttpOnly=True を設定することで、 JavaScriptからCookieを取り出せな いようにする • この設定は、XSS（クロスサイトスクリ プティング）攻撃の際に、悪意のある スクリプトがクッキーにアクセスするこ とを防ぐ
80. ドメイン属性を指定する • クッキーがどのドメインに対して有効 かを指定するための属性です。この 属性を設定することで、特定のサブド メイン間でクッキーを共有したり、適用 範囲を制限することができる。 • クッキーの有効範囲を制御し、どのド メインやサブドメインでクッキーが送信 されるかを決定する。
81. ドメイン属性を指定する • Domain 属性を指定することで、異なるサブドメイン間でクッキーを共有することが 可能。 • Domain 属性を設定すると、指定したドメインとそのサブドメインでもクッキーを送信 できるようになります ◦ 例えば、www.test.com で設定されたクッキーは、 www.test.com 下のサーバーのみリクエストに のみ送信され、api.test.com では送信されない。 ◦ 例えば、Domain=test.com と設定すると、www.test.com, api.test.com など、test.com 以下の全 てのサブドメインでクッキーが共有 されます。
82. ドメイン属性を指定する BackEnd WebAPI FrontEnd HTTP Request api.test.com www.test.com BackEnd WebAPI FrontEnd HTTP Request api.test.com www.test.com domain属性 test.com domain属性 www.test.com Cookieは付与されない
83. SameSite属性は付与した方がいい • SameSite属性は、クッキーがクロス サイトリクエストで送信されるかどうか を制御するためのセキュリティ機能 • この属性を設定することで、クッキー の送信範囲を制限し、特にCSRF攻撃 の防止に役立つ
84. SameSite属性は付与した方がいい • SameSite属性は、以下の3種類の設 定値がある ◦ Strict ◦ Lax ◦ None
85. SameSite属性は付与した方がいい（ SameSite=Strict) Strict • Cookieはクロスサイトリクエストに一切送信されない。 • つまり、他のドメインからのリクエスト（リンクのクリックやフォーム送信など）では、そのクッキーは送信さ れず、クッキーが設定されたドメイン内でのみ有効。 • クロスサイト攻撃に非常に強い ◦ クッキーが送信されないため、他のサイトからの CSRF攻撃を防ぐことができる。 ◦ リンクをクリックして別のタブに遷移した場合や、他のサイトからのリクエストでクッキーが必要な場 合にも送信されないため、ユーザー体験に影響を与えることがあります。
86. SameSite属性は付与した方がいい（ SameSite=Lax) Lax • Cookieはクロスサイトリクエストでも送信されますが、安全なクロスサイトナビゲーションに限定される • 具体的には、GETメソッドのリクエストやリンクのクリックなどではクッキーが送信されるが、 POSTリクエス トや他の安全でないリクエストではクッキーが送信されない。 • セキュリティと利便性のバランスが取れる ◦ 通常のリンククリックや GETリクエストではクッキーが送信されるため、サイト間のナビゲーションが スムーズに行われます。 • CSRFに一定の防御 ◦ GET以外のリクエストではクッキーが送信されないため、 CSRF攻撃に対して一定の防御力を持って いる
87. SameSite属性は付与した方がいい（ SameSite=None) None • Cookieがクロスサイトリクエストにも常に送信される設定です。 • これは、iframe内やクロスサイトPOSTリクエストなど、あらゆるクロスサイトシナリオでクッキーが送信され る。 • 最も柔軟な設定 ◦ クロスサイトリクエストにもクッキーが送信されるため、サードパーティのサービスと連携するアプリ ケーション（例：OAuthプロバイダやCDN）がこの設定を必要とすることが多いです。 • セキュリティ上のリスクが高い ◦ クッキーがクロスサイトで送信されるため、 CSRF攻撃に対して脆弱になる可能性があります。
88. SameSite属性は付与した方がいい
89. JWTを使用するには、使用済みの JWT無効化が必要 ステートレス認証であるJWTの弱点として、一度発行してしまったトークンをサーバー側 でトークンを無効化できないところにある
90. JWTを使用するには、使用済みの JWT無効化が必要 ログアウトされたJWTをブラックリストとしてしばらく管理するという方法がある ブラックリストに載せられたJWTをしばらくはじくという方法でログアウト済みのトークンを 無効化できる 実際の運用では、Redisやデータベースを使ってブラックリストを管理するのが一般的で す。
91. 一番安全なのは Auth0などを利用した認証 • Auth0ではインメモリにトークンを保存している。 • タブを閉じたタイミングで消えるが、再度ページにアクセスしたときに認証状態を維 持するにはどうしているかというと、Auth0のサーバとはCookieでセッションを維持 しておき、トークンが有効でないとき（タブを閉じて消えたとき、トークンの有効期限 が切れたとき）にAuth0のサーバから取得している • iframeやweb workerを駆使して、トークンの取得と管理を行っているとのこと SPA認証トークンはlocalStorageでもCookieでもない、Auth0方式はいいねというお話 https://mizumotok.hatenablog.jp/entry/2021/08/04/114431
92. まとめ
93. まとめ • SPA + WebAPIの構成をとる場合、ステートレスでセッション認証を行うような構成 を主に紹介 • ステートレス認証となるとJWTなどを使ったトークンがある • CookieのDomain, HttpOnly, Secure, SameSiteなどの属性を設定して、トークンの 持ち方はかなり重要になる • セッション認証とトークン認証の良いとこ取りをすると実装がやりやすい • 余裕があるならAuth0などを用いた実装が一番安全
94. 最後に紹介
95. 弊社から4人が登壇