ファストAPI

第11章 認証認可

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

権威に敬意を払え！

エリック・カートマン（サウスパーク

プレビュー

Webサイトがオープンで、どんな訪問者でもどのページでも閲覧できる場合もある。 しかし、サイトのコンテンツが変更される可能性がある場合、一部のエンドポイントは特定の人やグループに制限されることになる。 アマゾンのページを誰でも変更できるとしたら、奇妙なアイテムが表示されたり、ある人が突然驚くような売上を達成したりすることを想像してみてほしい。 残念ながら、一部の人間にとっては、その活動に対して隠れた税金を払っている残りの人間を利用するのが人間の本性なのだ。

クリプトサイトは、どのユーザがどのエンドポイントにアクセスしてもいいようにオープンにしておくべきなのだろうか？ いや、そうではない。ほとんどどんな大規模なウェブサービスでも、最終的には次のような対処が必要になる：

認証（authn）

君は誰だ？

認証 (authz)

何が望みだ？

認証認可(auth)コードは、ウェブとサービスの間など、それ自身の新しいレイヤーを持つべきなのだろうか？ それとも、すべてをウェブやサービスレイヤー自身で処理すべきなのだろうか？ この章では、認証のテクニックと、それをどこに置くべきかについて掘り下げていく。

ウェブ・セキュリティに関する説明は、必要以上に混乱しているように見えることがよくある。 攻撃者は本当に、本当に卑劣で、対策は単純ではないかもしれない。

注

何度も言っているように、FastAPIの公式ドキュメントは素晴らしい。 この章に思うように詳細が書かれていない場合は、セキュリティのセクションを読んでみてほしい。

では、このウォークスルーを順を追って説明しよう。 テスト用のWebエンドポイントに認証をフックすることだけを目的とした、簡単なテクニックから始めるが、公開Webサイトでは耐えられないだろう。

間奏曲1：認証は必要か？

繰り返しになるが、認証は「あなたは誰なのか」というアイデンティティに関わるものである。 認証を実装するには、秘密情報を一意なアイデンティティにマッピングする必要がある。 これには多くの方法があり、複雑さのバリエーションも多い。 まずは小さく始めて、上達していこう。

ウェブ開発に関する本や記事は、認証と認可の詳細にすぐに飛びつき、時にはそれらを混同してしまうことがよくある。 彼らは最初の質問である「どちらも本当に必要なのか」を飛ばしてしまうことがある。

Webサイトの全ページへの完全な匿名アクセスを許可することもできるが、それではサービス拒否攻撃のような悪用にさらされる可能性がある。 レート制限のようないくつかの保護はWebサーバの外部で実装することができるが（第13章参照）、ほとんどすべてのパブリックAPIプロバイダは、少なくともいくつかの認証を必要とする。

セキュリティだけでなく、Webサイトがどの程度効果的なのかも知りたい：

• ユニークビジター数は？

• 最も人気のあるページは何か？

• いくつかの変更は再生回数を増やすのだろうか？

• どのようなページシーケンスが一般的なのか？

これらの質問に対する回答は、特定の訪問者の認証が必要である。 さもなければ、合計カウントしか得られない。

注

サイトが認証や認可を必要とする場合、攻撃者がプレーンテキストから秘密データを抽出するのを防ぐために、サイトへのアクセスは暗号化されるべきである（HTTPの代わりにHTTPSを使用する）。 ...