How best to support IoT API keys tied to users in Fief?

[matteius]

I am quite excited about Fief and the OAuth2 flows -- last night I got my grafana logins working with the Fief OAuth2 flow, and this morning I got the GitHub connector to work, awesome!

The next problem I want to solve is related to User's IoT devices, for which OAuth2 is too heavy of a flow/not realistic for a modern IoT MCU where it typically gets deployed with static API keys. In my ideal world, users would be able to provision device API keys for themselves. From there I have to consider that there is a need to tie a device identifier to an API key (so that two devices can't report data with the same identifier) and mark that registered device identifier as either private or public.

In my example, the IoT data lives in MongoDB (powered by FastAPI) and the Fief user data lives in its own Postgresql schema related to the Fief workspace. I am still trying to think through the best path forward for modeling this and connecting the dots. Any insights or suggestions you might have in this space would be greatly appreciated. Thanks!

[frankie567]

Well, I think it depends how your users will provision their device. The easiest way IMO would be to implement your own API key mechanism for your device and tie them to Fief users.

If we imagine that your users have access to a web application where they can manage their devices and data. This web application uses Fief for authentication.

When they receive their device, users can login to the web application and register their device using the unique device ID. At that point, you can store in your MongoDB that the device 1 is tied to user having the Fief ID A. In addition, you can generate and store alongside this an API key.

The user would then need to set this API key on the device (don't know how).

During usage, your device will send data to the backend using this API key, which you can simply check from your database.

I'm not very experienced in IoT, so this may not make totally sense, but probably worth to explore in this way.

[matteius]

Thanks for your response and actually this makes a lot of sense and this captures really well what I was already imagining:

If we imagine that your users have access to a web application where they can manage their devices and data. This web application uses Fief for authentication.

I'm still thinking through how the subsequent steps will work. I started with the Fast API guide and was able to use the Oauth grant in docs/ and now I have converted that to follow the Web Application example, and this protected route redirects to to Fief login if the cookie is not set. https://api.opensensor.io/protected

I also followed the Fief nextjs integration and can login to my nextjs UI, so I was thinking there is probably a way to pass the cookie along from the parent app to the api subdomain so that something like this /protected route would detect the existing auth and it could return a JSON response instead of rendering the HTML page from the example. Does that even make sense? Now that I've explained it, I am thinking maybe its better to request the access_token_info from in nextjs and supply that to the REST FastAPI layer, but this part isn't clear to me yet.

The other thing I considered briefly was if the user created webhook serves some value, but I think if I understand it right, with an authenticated user I should be able to get the user info from fief in real time, or at least enough info to map the user to other entities.

The user would then need to set this API key on the device (don't know how).

There isn't a great way to automate storing the API key on the device, it basically involves editing a config.py on the MCU to set the API Key, but I am expecting this. Maybe one day the micropython pico bluetooth support will get merged and it could be possible to configure it via bluetooth, but I am not 100% sure on that.

[matteius]

Oh, and comparing the data returned by FiefAuth it seems the sub is the same as the user uuid key? That will be perfect

{'sub': '<redacted>', 'email': '<redacted>', 'tenant_id': '<redacted>', 'is_active': True, 'is_superuser': False, 'is_verified': False, 'fields': {}}

[frankie567]

Since you have a dedicated frontend taking care of the OAuth2 flow, I would suggest to keep your backend as a pure REST API that'll just check the validity of an access token given in Authorization header, as per the API example. The auth.authenticated() dependency gives you a FiefAccessTokenInfo dictionary, which contains the id of the user.

From your NextJS frontend, you should have been able to retrieve the access token using useFiefAccessTokenInfo. In the current version, I've deliberately omit the access token from it, but after second thought, I don't see why it's useful. I'll make a patch so the access token is included.

When this is available, you'll be able to call your backend with the access token. Something like:

 const response = await window.fetch(
    'http://backend.mydomain.com/devices', {
        headers: {
            'Content-Type': 'application/json',
            'Authorization': `Bearer ${ACCESS_TOKEN}`
        },
    },
);

➡ For this to work in the browser, you'll likely need to set up CORS if your backend and frontend are not on the same domain. Ref: https://fastapi.tiangolo.com/tutorial/cors

---

The other thing I considered briefly was if the user created webhook serves some value, but I think if I understand it right, with an authenticated user I should be able to get the user info from fief in real time, or at least enough info to map the user to other entities.

Webhooks are more suited when you want to trigger additional logic when specific events happen, e.g., add the user to a CRM. They typically happen in the background and do not involve user interaction.

[frankie567]

Available in 0.12.3, with related documentation: https://docs.fief.dev/integrate/javascript/ssr/nextjs/#get-access-token

[matteius]

Thanks @frankie567 -- this update and your example is working great!