Heim  >  Artikel  >  Backend-Entwicklung  >  FastAPI-Authentifizierung mit Abhängigkeitsinjektion

FastAPI-Authentifizierung mit Abhängigkeitsinjektion

Patricia Arquette
Patricia ArquetteOriginal
2024-09-24 06:21:091000Durchsuche

FastAPI Auth with Dependency Injection

FastAPI ist ein modernes Webframework zum Erstellen von APIs in Python. Es ist eines meiner persönlichen Lieblings-Webframeworks, da es integrierte Unterstützung für OpenAPI-Spezifikationen bietet (das heißt, Sie können Ihren Backend-Code schreiben und alles daraus generieren) und Abhängigkeitsinjektion unterstützt.

In diesem Beitrag schauen wir uns kurz an, wie Depends von FastAPI funktioniert. Wir werden dann sehen, warum es so gut auf Authentifizierung und Autorisierung anwendbar ist. Wir werden es auch mit Middleware vergleichen, einer weiteren häufigen Option für die Authentifizierung. Abschließend schauen wir uns einige erweiterte Muster für die Autorisierung in FastAPI an.

Was ist Dependency Injection?

Eine der leistungsstärkeren Funktionen von FastAPI ist die erstklassige Unterstützung für Abhängigkeitsinjektion. Wir haben hier eine längere Anleitung, aber schauen wir uns ein kurzes Beispiel an, wie es verwendet werden kann.

Nehmen wir an, wir erstellen eine paginierte API. Jeder API-Aufruf kann eine Seitennummer und eine Seitengröße enthalten. Jetzt könnten wir einfach eine API erstellen und diese Parameter direkt übernehmen:

@app.get("/things/")
async def fetch_things(page_number: int = 0, page_size: int = 100):
    return db.fetch_things(page_number, page_size)

Aber wir möchten wahrscheinlich eine Validierungslogik hinzufügen, damit niemand nach Seitennummer -1 oder Seitengröße 10.000.000 fragt.

@app.get("/things/")
async def fetch_things(page_number: int = 0, page_size: int = 100):
    if page_number < 0:
        raise HTTPException(status_code=400, detail="Invalid page number")
    elif page_size <= 0:
        raise HTTPException(status_code=400, detail="Invalid page size")
    elif page_size > 100:
        raise HTTPException(status_code=400, detail="Page size can be at most 100")
    return db.fetch_things(page_number, page_size)

Und das ist... in Ordnung, aber wenn wir 10 APIs oder 100 APIs hätten, die alle die gleichen Paging-Parameter benötigen, würde es etwas mühsam werden. Hier kommt die Abhängigkeitsinjektion ins Spiel – wir können die gesamte Logik in eine Funktion verschieben und diese Funktion in unsere API einfügen:

async def paging_params_dep(page_number: int = 0, page_size: int = 100):
    if page_number < 0:
        raise HTTPException(status_code=400, detail="Invalid page number")
    elif page_size <= 0:
        raise HTTPException(status_code=400, detail="Invalid page size")
    elif page_size > 100:
        raise HTTPException(status_code=400, detail="Page size can be at most 100")
    return PagingParams(page_number, page_size)

@app.get("/things/")
async def fetch_things(paging_params: PagingParams = Depends(paging_params_dep)):
    return db.fetch_things(paging_params)

@app.get("/other_things/")
async def fetch_other_things(paging_params: PagingParams = Depends(paging_params_dep)):
    return db.fetch_other_things(paging_params)

Das hat einige nette Vorteile:

  • Jede Route, die PagingParams aufnimmt, wird automatisch validiert und verfügt über Standardwerte.

  • Es ist weniger ausführlich und fehleranfällig, als wenn die erste Zeile jeder Route „validate_paging_params(page_number, page_size)“ wäre

  • Dies funktioniert weiterhin mit der OpenAPI-Unterstützung von FastAPI – diese Parameter werden in Ihren OpenAPI-Spezifikationen angezeigt.

Was hat das mit der Authentifizierung zu tun?

Es stellt sich heraus, dass dies auch eine großartige Möglichkeit ist, die Authentifizierung zu modellieren! Stellen Sie sich vor, Sie hätten eine Funktion wie:

async def validate_token(token: str):
    try:
        # This could be JWT validation, looking up a session token in the DB, etc.
        return await get_user_for_token(token)
    except:
        return None

Um dies mit einer API-Route zu verbinden, müssen wir es nur in eine Abhängigkeit einschließen:

async def require_valid_token_dep(req: Request):
    # This could also be a cookie, x-api-key header, etc.
    token = req.headers["Authorization"]
    user = await validate_token(token)
    if user == None:
        raise HTTPException(status_code=401, detail="Unauthorized")
    return user

Und dann können alle unsere geschützten Routen diese Abhängigkeit hinzufügen:

@app.get("/protected")
async def do_secret_things(user: User = Depends(require_valid_token_dep)):
    # do something with the user

Wenn der Benutzer ein gültiges Token bereitstellt, wird diese Route ausgeführt und der Benutzer wird festgelegt. Andernfalls wird eine 401 zurückgegeben.

Hinweis: OpenAPI/Swagger bietet zwar erstklassige Unterstützung für die Angabe von Authentifizierungstoken, Sie müssen dafür jedoch eine der dedizierten Klassen verwenden. Anstelle von req.headers["Authorization"] können Sie HTTPBearer(auto_error=False) von fastapi.security verwenden, das HTTPAuthorizationCredentials zurückgibt.

Middleware vs. Abhängig von der Authentifizierung

FastAPI verfügt, wie die meisten Frameworks, über ein Konzept der Middleware. Ihre Middleware kann Code enthalten, der vor und nach einer Anfrage ausgeführt wird. Es kann die Anfrage ändern, bevor die Anfrage Ihre Route erreicht, und es kann die Antwort ändern, bevor sie an den Benutzer zurückgegeben wird.

In vielen anderen Frameworks ist Middleware ein sehr häufiger Ort für Authentifizierungsprüfungen. Dies liegt jedoch häufig daran, dass die Middleware auch die Aufgabe hat, den Benutzer in die Route einzubinden. Ein häufiges Muster in Express besteht beispielsweise darin, Folgendes zu tun:

app.get("/protected", authMiddleware, (req, res) => {
    // req.user is set by the middleware
    // as there's no good way to pass in extra information into this route,
    // outside of the request
});

Da FastAPI über ein integriertes Injektionskonzept verfügt, müssen Sie möglicherweise überhaupt keine Middleware verwenden. Ich würde die Verwendung von Middleware in Betracht ziehen, wenn Sie Ihre Authentifizierungstoken regelmäßig „aktualisieren“ müssen (um sie am Leben zu halten) und die Antwort als Cookie festlegen müssen.

In diesem Fall möchten Sie request.state verwenden, um Informationen von der Middleware an die Routen zu übergeben (und Sie können eine Abhängigkeit verwenden, um request.state zu validieren, wenn Sie möchten).

Andernfalls würde ich bei der Verwendung von Depends bleiben, da der Benutzer direkt in Ihre Routen eingefügt wird, ohne dass er request.state durchlaufen muss.

Autorisierung – Mandantenfähigkeit, Rollen und Berechtigungen

Wenn wir alles anwenden, was wir bisher gelernt haben, kann das Hinzufügen von Mandantenfähigkeit, Rollen oder Berechtigungen ziemlich einfach sein. Nehmen wir an, wir haben für jeden unserer Kunden eine eindeutige Subdomain. Wir können eine Abhängigkeit für diese Subdomain erstellen:

async def tenant_by_subdomain_dep(request: Request) -> Optional[str]:
    # first we get the subdomain from the host header
    host = request.headers.get("host", "")
    parts = host.split(".")
    if len(parts) <= 2:
        raise HTTPException(status_code=404, detail="Not found")
    subdomain = parts[0]

    # then we lookup the tenant by subdomain
    tenant = await lookup_tenant_for_subdomain(subdomain)
    if tenant == None:
        raise HTTPException(status_code=404, detail="Not found")
    return tenant

Wir können diese Idee mit unseren vorherigen Ideen kombinieren und eine neue „Multi-Tenant“-Abhängigkeit erstellen:

async def get_user_and_tenant_for_token(
    user: User = Depends(require_valid_token_dep),
    tenant: Tenant = Depends(tenant_by_subdomain_dep),
) -> UserAndTenant:
    is_user_in_tenant = await check_user_is_in_tenant(tenant, user)
    if is_user_in_tenant:
        return UserAndTenant(user, tenant)
    raise HTTPException(status_code=403, detail="Forbidden")

Wir können diese Abhängigkeit dann in unsere Routen einfügen:

@app.get("/protected")
async def do_secret_things(user_and_tenant: UserAndTenant = Depends(get_user_and_tenant_for_token)):
    # do something with the user and tenant

Und das bewirkt letztendlich ein paar wichtige Dinge:

  • Überprüfen, ob der Benutzer über ein gültiges Token verfügt

  • Überprüfung, ob der Benutzer eine Anfrage an eine gültige Subdomain stellt

  • Überprüfen, ob der Benutzer Zugriff auf diese Subdomain haben sollte

If any of those invariants aren’t met - an error is returned and our route will never run. We can extend this to include other things like roles & permissions (RBAC) or making sure the user has a certain property set (active paid subscription vs no active subscription).

PropelAuth <3 FastAPI

At PropelAuth, we’re big fans of FastAPI. We have a FastAPI library that will enable you to set up authentication and authorization quickly - including SSO, Enterprise SSO / SAML, SCIM Provisioning, and more.

And it all works with dependencies like the ones you’ve seen above, e.g.:

@app.get("/")
async def root(current_user: User = Depends(auth.require_user)):
    return {"message": f"Hello {current_user.user_id}"}

You can find out more here.

Summary

  • FastAPI's dependency injection provides a powerful way to handle authentication and authorization in web applications.

  • The Depends feature allows for clean, reusable code for validating tokens, checking user permissions, and handling multi-tenancy.

  • Compared to middleware, using dependencies for auth offers more flexibility and direct integration with route functions.

  • Complex authorization scenarios like multi-tenancy and role-based access control can be efficiently implemented using nested dependencies.

  • PropelAuth offers a FastAPI library that simplifies the implementation of advanced authentication and authorization features.

Das obige ist der detaillierte Inhalt vonFastAPI-Authentifizierung mit Abhängigkeitsinjektion. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn