FastAPI

Chapter 11. Authentication and Authorization

Respect mah authoritay!

Eric Cartman, South Park

Preview

Sometimes a website is wide open, and any visitor can visit any page. But if any of the site’s content may be modified, some endpoints will be restricted to certain people or groups. If anyone could alter pages on Amazon, imagine the odd items that would show up, and the amazing sales some people would suddenly get. Unfortunately, it’s human nature—for some humans—to take advantage of the rest, who pay a hidden tax for their activities.

Should we leave our cryptid site open for any users to access any endpoint? No! Almost any sizable web service eventually needs to deal with the following:

Authentication (authn)

Who are you?

Authorization (authz)

What do you want?

Should the authentication and authorization (auth) code have its own new layer, say between Web and Service? Or should everything be handled by the Web or Service layer itself? This chapter dips into auth techniques and where to put them.

Often descriptions of web security seem more confusing than they need to be. Attackers can be really, really sneaky, and countermeasures may not be simple.

Note

As I’ve mentioned more than once, the official FastAPI documentation is excellent. Try the Security section if this chapter doesn’t provide as many details as you’d like.

So, let’s take this walk-through in steps. I’ll start with simple techniques that are intended to only hook auth into a web endpoint for testing, ...