Help needed on OpenID flow

[schwannden]

[re-post the discussino from an email thread]
I have a project that clearly separates frontend and backend apps, and I read the tutorial for setting up backend fastapi with fief, I don't really understand how to proceed. In the tutorial it uses fastapi's swagger doc to demonstrate the login flow, which requires us to input oauth client id and client secret, and then authorize with swagger doc.

So in my scenario, I still implement the similar code (as in tutorial) in the backend fastapi app, but how should I set up the frontend part of the code? When frontend app clicks login, should I be asking the backend app to send me auth_url? Or should I add client id to frontend so that frontend can generate auth_url on its own? And in either way, after the auth_url grant is successful, I only get a code, and I am supposed to use the code to further get my access token and id token right? then should I be using the backend or frontend to fetch these 2 tokens? And where should I be storing these tokens?

[schwannden]

response from @frankie567
Well, it’ll depend on the nature of your frontend. Typically, if you build a frontend with a framework like React, I would suggest to make the OAuth connection on the frontend side. There is a SDK and instructions about how to go with this in JS: https://docs.fief.dev/integrate/javascript/ Basically, you’ll maintain the access token and ID token in browser memory. When you make API requests to your backend, you can read the access token and pass it in an Authorization header.

Then, on your backend, you could just go with the basic FastAPI example: it’ll just wait for the access token passed in headers and validate it. The backend doesn’t know / care about how to ask for a fresh token, it just uses it.

Hope it clarifies things a bit!

[schwannden]

If I understand correctly, we'll be using frontend to get a temporary code, called the authorization code. Then backend can use this authorization code to get stuff like authorization token or ID token (this step verifies the user supplies a valid code, which means the user is signed in and authenticated). And then it would be our backend's responsibility to manage and maintain our own session right? For example, after getting ID token, we may respond to frontend with set-cookie directive to set this value to a http-only, secure cookie.

[frankie567]

Well, that could work like this, but I think it's better to either do everything in the frontend or everything in the backend.

Everything in frontend

1. The frontend redirects to the Fief authorization page
2. After successful login, Fief redirects to the frontend with the authorization code
3. The frontend makes an AJAX request to Fief to exchange the authorization code with an access token and an ID token
4. The frontend stores the tokens in local storage (for example)
5. Whenever you make an API request to the backend, the frontend makes sure to set the access token in the Authorization header of the HTTP request.
6. On the backend side, the Fief SDK will check if the access token is valid before running your endpoint logic

Step 1-4 is what is done is the JS browser example : https://docs.fief.dev/integrate/javascript/browser/#application-example The SDK even takes care of the PKCE mechanism for extra security in this context.

Step 6 is what is shown in the FastAPI API example : https://docs.fief.dev/integrate/python/fastapi/#api-example

Everything in backend

1. The backend generates a redirection to the Fief authorization page
   • In the web application example, we automatically redirect to the authorization page if the user tries to access a protected page
   • In an API context, it may be better to leave the default handler (which simply returns a 401 response), and implement a special route which sole responsibility is to redirect us to the Fief authorization page. Something like this:

@app.get("/authorize", name="authorize")
async def authorize(request: Request):
    redirect_uri = request.url_for("auth_callback")
    auth_url = await fief.auth_url(redirect_uri, scope=["openid"])
    return RedirectResponse(auth_url)

2. After successful login, Fief redirects to the /auth-callback route with the authorization code
3. The backend exchanges the authorization code with an access token and an ID token
4. The backend stores the access token in a session cookie and redirects to the frontend
5. Now, whenever the frontend makes an API request to the backend, the browser will automatically send the session cookie containing the access token.
6. On the backend side, the Fief SDK will check if the access token is valid before running your endpoint logic

Which is better?

• The first solution is more "REST-ful" and more suitable if you plan to use it as a pure API. Besides, if you plan to develop a mobile app in the future, nothing will have to change in your backend: the mobile app will take care of retrieving a token from Fief, exactly like the frontend.
• The second solution is nice for web applications that are designed to work in the browser. Cookies are very good to store the token and you don't even have to care about them when making requests to your backend, as they are handled automatically.

[schwannden]

Thank you for the detailed reply. I am more familiar with cookie than bearer token, and I am not sure about the following point

1. If we are storing access token in frontend, do we have control over the lifetime of this access token when we request it? Or is this a permanent token (if scope requested and user information has remained the same)?
2. In backend, what is the mechanism for validating this access token, does it go to fief every time? Or has some sort of cache mechanism been implemented? What will happen to validation if Fief server is offline?

[frankie567]

The access token and ID token generated by Fief are JWT. It has several benefits:

• Its validity and authenticity can be checked directly without a roundtrip to the Fief server thanks to its cryptographic signature.
• The lifetime is embedded in the token. It's also verified after the signature, so if it's expired, it'll be rejected. Tokens' lifetime in Fief are set to 3600 seconds.

When storing the access token on your frontend, it'll become invalid after an hour. At that point, you'll need to ask for a fresh token. There are two ways of doing this:

1. Simply make an authentication again by redirecting the user to Fief authorization page. The good thing is that Fief remembers the user on its side, so the user won't have to input its credentials: Fief will directly redirect them to the callback route.
2. Use the refresh token. If you ask for the offline_access scope, you'll get a third token, refresh_token. It can be used to ask directly for fresh access and ID tokens, either in the frontend or in the backend.

[schwannden]

I see, that resolves all my questions. Thank you!

[schwannden]

Reopening this discussion. If we are doing everything in the frontend (quote: The frontend makes an AJAX request to Fief to exchange the authorization code with an access token and an ID token), aren't we putting client secret in the frontend? Isn't this a bad idea (security wise)?
c.c. @frankie567

[frankie567]

For this, you'll have to use a Public Client. In this configuration the Client Secret is not required. However, the PKCE mechanism is required (it's handled automatically by our JS SDK).