I’m starting a new project, and after testing my own JWT Auth, I think OAuth2 with an IdP like Firebase would be a better solution.
I found too much resources, butI’m now a bit confused.
- Firebase doc’ : Authenticating Users on App Engine Using Firebase
- Auth0 doc’ : Backend For Frontend Authentication Pattern with Auth0 and ASP.NET Core
- Reddit : Securing FastAPI with JWT Token-based Authentication
- Stackoverflow : The complete guide to protecting your APIs with OAuth2 (I couldn’t find the part2?)
- Redis : Client-side caching in Redis
About my Project :
- Frontend: Vue 3 (with Quasar) + Pinia
- Backend: FastAPI + firebase-admin
- Redis, PostgreSQL
Side note:
I think the Diagram 1 make more sense, but I would like the advice of someone more experimented in oAuth. (pro/con of each diagram?)
I’m not familiar with Caching/Redis, but I read on the Auth0 Community, they recommended to cache the tokens, so the IdP will issue less tokens, and it will reduced the cost.
Questions :
- Which diagram/workflow would be the most secure and would you prefer ?
- I think it’s possible to cache the tokens at the frontend level, but is it enough secure ?
2
Answers
If you use Firebase auth you will use their web SDK (or one of the other client side SDKs) on client side and their admin SDK on server side. Firebase will handle the caching, tokens, etc. When you pass your request to the server the admin SDK can verify the auth before you process the request.
Normally you would create a Firebase user after the getting their OAuth Token. For example, when using Google as the OAuth provider, the first half would be like:
See the documentation for complete diagram and flow.
After you get the response, you can call the sign in user with OAuth credential that will create a user in Firebase Authentication. Thereafter, you can use Firebase’s pair of access and refresh tokens to authenticate user on your backend. See verify Firebase ID Tokens.
A Firebase ID Token is a JWT generally used as a bearer token that essentially means if you have the token, you have the permission to access given resources. You can just store the tokens on client’s device and send them in API request and verify them every time. Only caching I can think of is storing a key-value pair where key is the token and value is user’s ID so you don’t have to verify the token every time but I would just verify them.
When using Firebase Client SDKs, you don’t have to deal with all this but just use built it methods like
signInWithPopup()and Firebase will do this behind the scenes.