Need guidance about integration with FastAPI service

[ocontant]

I would need some guidance about how to integrate Fief with a FastAPI service. Also, what are the best practices and architecture patterns to consider.

The way I envision the integration with Fief is:
It should handle all user management, authentication, session management, JWT Token lifecycle, user attributes and methods for user lifecycle. My apps should query Fief whenever there is a user event involved, like registration, authentication, session validation, tokens management, permissions and roles.

Integration paradoxes

1. Since Fief support custom user fields via the methods exposed in "user-fields", I was thinking to leverage this capability to extend users fields for the context of my application, and only keep a cache copy of the object in my local context via the session management context. The alternative would be to copy the user locally to the context of my app and fetch UID, Email and other shared fields from Fief (comes syncing the data disadvantage).

2. Session management:
   This comes as a challenge to me, as I couldn't find guidance on the subject. I was hoping to have session lifecycle managed by Fief, with methods exposed to get a JWT tokens, decodes, encodes, and so on. But it seems that I have to manage JWT session locally in my application instead, which I was hoping to abstract to Fief.

3. The FastAPI library for Fief Client, I couldn't find much documentation about it. My understanding is that I should be able to use it as a Middleware library to integrate fief in my apps. Or Should I build a Middleware component in my apps around the Fief Client to abstract in my apps the interface for user management?

[fief-bailiff[bot]]

Hail, @ocontant 👋 Welcome to Fief's kingdom!

Our team will get back to you very soon to help.

In the meantime, take a minute to star our repository ⭐️

Farewell!

[frankie567]

Hi @ocontant 👋

There are several examples and code snippets for FastAPI right here: https://docs.fief.dev/integrate/python/fastapi/

Have you tried them? It looks to me that it should answer most of your questions.

[ocontant]

This is the documentation i have been following, plus reading the code (with my limited capacity) of the fief client.

It's more about my inexperience about design pattern and integration pattern. There are multiple way to implement and integrate, and since I miss point of references, I don't know which way to go. AKA the questions I described above.

I was thinking, of having an open discussion to dig my level of ignorance and find what I'm missing.
Also an opportunity to plunge in the beginner mind and identify the culprit patterns, that could be used afterward to enhanced and improve the documentation.

[frankie567]

Great! So, I'll try bring some clarifications to your questions:

1. Regarding user fields, you can indeed have a local cache to avoid having to ask them again to the Fief API. We show an example of this here: https://docs.fief.dev/integrate/python/fastapi/#caching-user-information It shows a simple in-memory cache, but it can be something more advanced, e.g. using Redis.

It's worth to note that you don't necessarily need to use user fields, if that doesn't fit your needs. You can very have your own mechanism to store user profile data and dedicated forms in your app. Your choice!

---

2. After a successful authentication in Fief, you get a valid JWT generated by Fief. It contains the user ID and its permissions. It is cryptographically signed by Fief, so the client (i.e. your app) can make sure it's a genuine token. That's what the Fief Client automatically does when we're doing this:

@app.get("/user")
async def get_user(
    access_token_info: FiefAccessTokenInfo = Depends(auth.authenticated()),  
):

The authenticated() dependency will automatically:

1. Retrieve the JWT in headers
2. Validate its signature
3. Return you the decoded data (or raise a 401 error if the JWT is invalid).

That's basically what Fief does: issue valid tokens to prove the identity of a user.

Now, there is another part in your question: how the client (i.e. a web page or a mobile application) remembers this token for subsequent requests? That's where you have the choice. For a mobile application, it'll probably be stored in the phone storage.

For a web app, the usual way is to use a cookie. That's what we show in this example: https://docs.fief.dev/integrate/python/fastapi/#web-application-example Basically, we tell the browser to store the JWT generated by Fief in a cookie, and send it us again on subsequent requests. That's all we need to do.

I think your question comes from the fact that some auth services act like a proxy, meaning all incoming requests first come through the auth service, read or set the cookie and then forward to your app with the user data ready to use. That's not the design we chose for Fief.

---

3. The client for FastAPI should be used as described in the examples. We fully embrace the dependency injection pattern of FastAPI, so we don't need middleware. If you look at this snippet:

@app.get("/protected", name="protected")
async def protected(
    user: FiefUserInfo = Depends(auth.current_user()),  
):
    return HTMLResponse(
        f"<h1>You are authenticated. Your user email is {user['email']}</h1>"
    )

You can see that we call Depends(auth.current_user()). It means that FastAPI will automatically call the current_user() logic when a request comes. Under the hood, lot of things happen (in particular, of course, validating the access token). But when your own logic starts below, you know that you have a valid user object at hand.

If you're not familiar with dependency injection with FastAPI, you should have a look at their tutorial, it's very interesting and helpful: https://fastapi.tiangolo.com/tutorial/dependencies/

[ocontant]

Thank you for the clarifications.
I now understand that I don't need to construct a Middleware for Fief, as the class are already designed to be integrated with FastAPI and the dependency management mechanism. (I will read more on the topic following your reference, and get back on it if i can add more context for other beginner readers).

Thanks for pointing out that the return from authenticated() is already decoded. I was expecting an encoded (optionally encrypted) JWT token as a return. (After thought, it actually makes sense to save back & forth call, since decoding would be the logical next step in the backend context).

I intend to use Redis as caching system. But I haven't start yet on that logic and I need to learn more about caching mechanism and integration pattern. I also have to figure out how to manage the signal communication to refresh caching when user data are updated. Maybe a case for a webhook, or Event-Driven Architecture, or a flow in the methods that update the data. (If there's a best practice design pattern for async micro-services cached data refresh, feel free to share).

1. I think using the extend fields capability of Fief appears to be the better design approach. The logic already exist in Fief, and I can always extend custom pydantic models and validation, while retrieving the field value from Fief.
   To create new user fields, does the fief_client support this directly?

2. After Rereading the documentation and extending my search on Google on the subject, I realized that there are 2 contexts of authentication design to consider for interactive User:

• First approach: Authentication is managed by the FrontEnd, and the token would be passed by the FrontEnd to the backend. The backend in that context only validate the token with Fief auth validation endpoint.
• Second approach is if the backend serve html to the frontend (old web architecture flow), then the backend would do the authentication and would have to pass the token to the frontend in a cookie or something like that.

In my context, I have 2 authentication context:
1- micro-service to micro-service API authentication (backend to backend), not sure if Fief could manage this, as it would be an API keys management with an automatic rotation logic.
2- Frontend user authentication, with the flow described in the 2. first approach above.

I'll continue to explore and feedback as I progress.

[frankie567]

Regarding the cache mechanism, that's indeed the ideal/most correct setup. We support webhooks by the way: https://docs.fief.dev/api/webhooks/guide/

That said, I would recommend you to start simple and maybe have just a simple cache with expiration.

---

1. You can create new user fields using the admin dashboard or the Admin API (which doesn't have client, but it's quite straightforward to use it with a lib like HTTPX or requests): https://docs.fief.dev/api/

You can however update the values for an authenticated user with the client: https://fief-dev.github.io/fief-python/fief_client.html#Fief.update_profile

---

2. Exactly! That's the point of two FastAPI examples (pure API approach vs Web page approach).

Regarding "machine-to-machine" authentication, this is not something we support right now; but it's definitely a feature we would like to add in the future. For now, you could indeed have your own mechanism of private tokens.