So I'm using Firebase functions to connect with an API that uses OAuth 2.0 and I need a secure place to store sensitive credentials (the refresh token). However, the token needs to be generated on the fly, so I can't store it in an environment variable.
Where is the most secure place to store sensitive credentials in Firebase?
Thank you!
I typically keep such credentials in memory after it's been generated. That means that future invocations on the same container will use the same credentials, while on a new container my code will generate new credentials.
Related
I completely don't understand the next-auth documentation.
I understand you can use both JWT and sessions, but how do you tell next-auth which one you're using?
And where does next-auth store its sessions or JWTs? On the server or client-side?
NextAuth.js uses a JWT to save the user's session by default, when a database adapter is not used.
NextAuth.js by default uses JSON Web Tokens for saving the user's
session. However, if you use a database adapter, the database will be
used to persist the user's session. You can force the usage of JWT
when using a database through the configuration options. Since v4 all
our JWT tokens are now encrypted by default with A256GCM.
The JWT is stored in an httpOnly cookie, not accessible on the client-side.
You can use JWT to securely store information you do not mind the
client knowing even without encryption, as the JWT is stored in a
server-readable-only cookie so data in the JWT is not accessible to
third party JavaScript running on your site.
This is documented in NextAuth.js JSON Web Tokens FAQ section.
I have a firebase web app calling my Python API.
the user who is using my app does not need to login to use it but I still need to make sure that this request coming from my application
How can I verify the identity of the app sending the request?
There is no way to enforce that calls can only come from your application. In a database that is directly accessible from the internet, that is simply not possible. Anyone who can use your web app, can take the configuration data from that app and use the Firebase API to make their own calls.
That's why it's important that you enforce all business rules that you have for your database in Firebase's server-side security rules too. You can use these to enforce data structure, and (when combined with Firebase Authentication) ensure that all data access is authorized.
You can use Firebase Authentication without requiring your users to enter credentials by using anonymous authentication. This essentially gives your user a unique ID, that you can then use to identify that user (and the data they create) in security rules.
I'm creating an app using firebase authentication and I'm still new to authentication and authorization. What I have already done is implement firebase authentication in the front end, when a user signs up successfully it will request to the backendend and verify its idToken firebase admin. When it's verified, the user's data will then be stored in the database together with the uid returned in verifying the idToken.
All is working but I have no clear idea on the best practices on authentication, am I on the right track? From what I've read, authenticated client should also pass a token in the header.
Should I return the uid to the client and use it in the header? If so, should the backend use it to check if there's a matching token in the database every client request?
I'm really quite lost with the log in flow standards, any answers are much appreciated thank you.
All right, so the first thing to understand is that Firebase operates on a client-side paradigm, meaning that you actually don't need to and should carefully consider whether you need to conduct Firebase operations server side. In principle, you can do everything on javascript on the web browser. or Android app. or iOS app.
If you do decide to move some functions server side, next best solution is to do them as hosted cloud functions in firebase too. See:
Callable cloud functions
If for some reason you need to deploy and host your own code, then you can continue as you are, doing auth client side, passing the token, decoding the token with node admin, and manually checking the user permissions as applicable.
I'm developing a REST web API that will be used by mobile app clients. I don't want any other client to be able to access the API. Should I just require a password/token that will be used by the mobile apps? Isn't there a way for people to find that password by decompiling my app?
Yes, you cannot create an app with a secret embedded and expect the secret to stay secret.
If you ship the app with the secret (token, user/pass, private key, etc), that information is available in the binary, and someone motivated could extract it.
The normal practice is to install the app, then let the user of the application log in, and store a unique credential for future requests.
You could use OWIN OAUTH where a user of the client is required to authenticate and a Bearer authorization token is returned to the client that must be passed in to all secure requests on the WebAPI (a secure request on the WebAPI uses the Authorize attribute)
Take a look at this link http://bitoftech.net/2014/06/01/token-based-authentication-asp-net-web-api-2-owin-asp-net-identity/#comments
how to store access token after authentication in google Drive And please tell me how to auto refresh token if it is expired.
please provide example of it.
in my Web Application it stores Token in %AppData% Folder but i want to store in Sql Server database.
Thanks in advance.
You don't store the access token as it only lives for one hour. If you really really want to store it anyway (maybe as a kind of keepsake) it's just a simple string so store it as you would any other string. The thing you should be storing is the refresh token, which is also just a string.
You can store the refresh to SQL database.
As far as i know you can use this refresh token when the access token expires.
There are two ways to handle refresh tokens:
1. Create a service that checks all the access token and refresh ones that are due to expire.
2. Or request a new access token using refresh token whenever you get an access token expiry error from the server during api calls. And then request the same api call once the access token is managed.
I am not sure if these are the best ways to handle refresh token.
Also my other question is whether it is common to store the access token. Or are we supposed to just authorise and get new access token every time we make api calls.
Any recommendations and experiences would be really appreciated.
Cheers.