Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 16 days ago.
Improve this question
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 ?
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.
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.
Related
I am using firebase firestore as datastore for my web based application. The application has 2 different actors.
Supervisor: logs in via a common password set for all supervisors plus the ability to generate unique codes.
User: logs in via the unique code generated by the supervisor.
I am using cloud functions to do the heavy lifting for both actors. Now these functions are protected with cors and whitelist for origins.
I am trying to secure the routes created with cloud functions with a Auth Middleware relying on the concept of if the request is not from authenticated account or not.
I have created a email and password accounts for both actors for the frontend section of my application.
The question is if I am to go with firebase Auth api to get the refresh token and use it as jwt in the Middleware, will it be an issue since let's say 100 supervisor are connected and performing some tasks, and the same thing for the second actor ? Because after examining the refresh token it contains the uid of the account authenticated and using the same account for multiple connection is the blocking stone in this scenario.
the point of a token to be used in every operation is to validate the origin of the request
Firebase Authentication uses ID tokens to verify the user's identity, not the origin of requests. A malicious user in your scenario can get the credentials from the app, and use them in their own code - calling APIs on your Firebase project.
If you want to only allow calls from your own app, consider using the new App Check feature of Firebase.
I am trying Firebase to authenticate users for a website that was initially built on Flask (using the flask login workflow with a postgres DB). However, I am not sure that I have a correct understanding of what would be considered best practices when using Firebase.
I read through this article, which I think has led me down a suboptimal path when it comes to actually managing users.
My questions are:
Should all the Firebase authentication be handled in the javascript?
If so, should I use the request.headers on the backend to verify the identity of the user?
Any tutorials (aside from the Firenotes one, which I am working through) much appreciated.
Should all the Firebase authentication be handled in the javascript?
No, it doesn't have to be JavaScript. But in general, you'll find that most apps using one of the existing Firebase Authentication providers handle the sign-in of the user in their client-side code, with calls to the authentication server.
If so, should I use the request.headers on the backend to verify the identity of the user?
When calling REST APIs Firebase itself passes the ID token of the authenticated user in the Authorization header, so that's a valid approach indeed. On the server you can then verify that the ID token is valid, and decide what data this user has access to.
I'm trying to build an IFTTT service and connect it to my Firebase backend.
I need to authenticate user as indicated in the IFTTT docs:
https://platform.ifttt.com/docs/api_reference#service-authentication
IFTTT’s protocol supports OAuth2 authentication, including support for
refresh tokens if so desired.
Your service API should use access tokens for authentication and as a
source of identity. A single access token should correspond to a
single user account or resource owner on your service.
If refresh tokens are used, they must be non-expiring. If refresh
tokens are not used, access tokens must be non-expiring.
But I can only get short-lived access tokens from Firebase it seems. Where can I get or how can I generate such tokens from the Firebase auth SDK?
Update in response to #FrankvanPuffelen:
I'll create an IFTTT service running on a Node server (possibly simply Cloud Functions) that will use the Firebase RTDB to send formatted HTTP request back to IFTTT. IFTTT requires me to authorize user accounts. Their required UX is something like this:
If an IFTTT user tries to use my service on the IFTTT website,
an auth dialog for my service pops up.
The user logs in and confirms IFTTT's access to their data on my service.
Some OAuth 2.0 tokens are exchanged.
IFTTT servers will periodically send requests (authentified with those tokens) on behalf of the user to my server.
Part of the question is: Can I use the Firebase Auth API to get those tokens, etc. or do I need to create a new OAuth 2.0 "layer" with my own generated tokens for IFTTT?
PS: I'm very new to OAuth, so it's all a bit confusing to me, sorry if the question isn't very clear.
So IFTTT calls Cloud Functions, which then calls Realtime Database, and you want to authentication the IFTT user with Realtime Database. Is that correct? If so, you can either use an OAuth2 token or create a Firebase Authentication session cookie.
Use an OAuth2 token
I did this not too long ago for accessing the Realtime Database from Google Apps Script. The requirements are relatively simple (once you know them):
The OAuth2 tokens must be requested with the correct scopes: https://www.googleapis.com/auth/userinfo.email and https://www.googleapis.com/auth/firebase.database.
The OAuth2 access token must be present in the request to Realtime Database.
The authenticated user must be at least an editor on the Firebase project. Note that this is not a Firebase Authentication user, but a Google user account.
Also see:
How to integrate Firebase into Google Apps Script without using (deprecated) database secret
Use a Firebase Authentication session cookie
You can also use a Firebase Authentication session cookie, which can be longer-lived (up to 2 weeks) than a regular Firebase Authentication ID token (up to an hour). You'll want to set up a Cloud Function for creating the session cookie, call that from IFTTT, and then pass the session cookie with the IFTTT request and along to the Realtime Database.
For more on this, see:
the Firebase documentation on managing session cookies.
I'm posting my solution here, this is a rough draft of what I did at at the time.
I'm using this auth method: My API has users with non-expiring OAuth2 access tokens and have an Express server responding at a Firebase HTTPS Cloud Function endpoint. Currently, at the prototyping stage, it generates fake tokens from the UID that are successfully accepted by IFTTT.
It's a redirect-heavy authentification flow based on this old IFTTT api example: https://github.com/IFTTT/connect_with_ifttt_auth_sample
Here's the gist of it:
Tokens and Auth Codes are just randomized and encrypted UIDs for now.
/oauth/authorize redirects to my app.
The app asks the user if they want to authorize IFTTT
The app redirects to /oauth/authorize_user
/oauth/authorize_user generates a user-specific code and redirects the user to IFTTT with this code
IFTTT asks /oauth/token to exchange the code for a Bearer tokens.
IFTTT can now make requests on behalf of this user with this bearer token.
Sample code here: https://gist.github.com/nathanvogel/15ed311258b91d7ec3d25f44047780e2
I am implementing notifications within an action. I am able to register users. However, I am not able to figure out how to do the push notification.
As the sample code uses the SDK, I am now stuck at the part "Exchange key for an access token" found in this documentation.
Is it possible to do this without the SDK? using a rest service?
Yes... but...
There is a REST service that does this, in fact, the library ultimately calls it. It is the standard OAuth2 token exchange endpoint at https://www.googleapis.com/oauth2/v4/token. The catch is building the JWT that you can pass to this service. To quote Google's page on the subject:
Although your application can complete these tasks by directly
interacting with the OAuth 2.0 system using HTTP, the mechanics of
server-to-server authentication interactions require applications to
create and cryptographically sign JSON Web Tokens (JWTs), and it's
easy to make serious errors that can have a severe impact on the
security of your application.
For this reason, we strongly encourage you to use libraries, such as
the Google APIs client libraries, that abstract the cryptography away
from your application code.
In short, if you want to do this, you need to:
Create a JSON Web Token (JWT) which includes a header, a claim set, and a signature.
Request an access token from the Google OAuth 2.0 Authorization Server.
Handle the JSON response to get the access token.
Keep track of the lifespan of the access token and, when it expires and you need an access token, repeat steps 1-4.
Details are at
Using OAuth 2.0 for Server to Server Applications
I'm not familiar with C# libraries, however I've been told that Google's C# Client Library seems to support it, and the high level documentation for ServiceAccountCredential appears to be able to generate auth tokens from the credentials.
I am trying to choose between Auth0 and Firebase as my identity provider. I am building a SPA with a Backend API and I would like to use Auth0 or Firebase for all the logic regarding users/passwords/access rights and etc.
Auth0 uses OIDC, which is kinda standard, but IMHO overengineered and very complex. It has separate tokens for identity (ID Token) and for accessing backend resources (access token), whereas firebase uses a single token (if I understand correctly).
So my question here is what authentication mechanism is Firebase using and why a single token is enough in this case?
Firebase Authentication uses two token types:
a long-lived refresh token that identifies the user
a short-lived ID token that validates that the user has access to the backend services
So it sounds like the two are pretty similar.