When performing sign out with Firebase Authentication, does it requires internet connection to successfully execute the task? It seems you can use Firebase.auth.signOut() even without having internet connection. Does signOut method only deletes the session in the local database or cache?
Does signOut method only deletes the session in the local database or cache?
Yes, that's correct. The state of being "signed in" has nothing to do with the backend and has everything to do with the user token currently in use (specifically, that it is present and has not expired after one hour since the last refresh).
Related
I have a web application that deployed on Firebase Hosting and uses Firebase Authentication.
I also have a backend server, deployed on Google App Engine, that serve this app.
How can I get the Firebase-UID cookie in the backend server to validate the user?
I don't want to enforce the app to add the cookie content as a parameter for each request.
When I used the Google Identity Toolkit (merged into the Firebase Authentication since) it took a pretty long time to get an authentication token check done, so I didn't want to do it for each and every backend request.
So what I did was to perform it (typically) once per user session and, upon successful verification, create a unique memcache entry for the user and place its key in the user session info. So for subsequent requests for the same session I'd only check if the session info contains the memcache key and, if so, check if the corresponding memcache entry exists - a memcache key lookup is a lot faster than a token verification. The only thing needed to complete the picture is deletion of the memcache entry whenever the user logs out. If you want you can also enforce a token recheck after a certain amount of time - simply by setting the memcache entry's expiration time.
Note: the memcache entry can disappear anytime, which would require another token verification even if the user didn't log out - so multiple times per session. But in my case it was a rare enough occurrence.
I have implemented Firebase custom authentication using the firebase-admin library in Python on my server.
The first time I use the token, it works fine and I'm able to authenticate.
But if I restart my node.js application a few minutes later, I get the error:
The custom token format is incorrect. Please check the documentation.
Which I believe means that it has expired, even though I never logged out.
This does not seem to be working:
Once you've called authWithCustomToken successfully, you stay logged in forever (until you sign out explicitly) so you should be able to get devices to have a long-lived authentication session without minting long-lived custom tokens.
How do I explicitly save the authentication between application restarts? Or do I have to mint a new custom token on every restart?
Custom tokens are only valid for an hour. However, I'd suspect your caught error code to be something different. I'm personally on a quest to figure out how to best keep these tokens refreshed, but I do wonder if a deployed instance restarting might be an alternate cause of tokens being invalidated.
Does firebase auth still keep the user in offline mode of a progressive web app ?
How does firebase auth works if the app is in offline ? Would like to know the two scenario.
User want to login for the first time during the app is in offline (app is using pouchDB & CouchDB for sync)
User already signed in, but app became offline. Does this mode even still work with firebase auth ?
Regards,
Sowmyan
Authenticating the user requires an active connection. There is no way for Firebase to authenticate your users without connecting to its servers.
Once the user is authenticated, the app will continue working when the user goes offline. Firebase Database operations will be reading from the local cache and writing to a queue. Once the connection is restored, the user's authentication token is (if needed) refreshed and the writes are sent to the server.
Like the Facebook application, you only enter your credentials when you open the application for the first time. After that, you're automatically signed in every time you open the app. How does one accomplish this?
There's a commom line in all auto-login implementations
Upon an initial login, a token is received and stored on the client side
Upon subsequent visits, if token is available on the client side, the server resolves the identity and logs in automatically
Now concrete implementation variations can be numerous. The token can be a session ID (encripted or not), OAuth token, custom token, username and password should be avoided. Storing token can be on within a browser cookie, browser local storage, can have a server counter-part. Security is the major concern. Generally about the topic you can read more here https://softwareengineering.stackexchange.com/questions/200511/how-to-securely-implement-auto-login
You have an interesting explanation of how does Stackoverflow do it https://meta.stackexchange.com/questions/64260/how-does-sos-new-auto-login-feature-work.
I'm working on an ASP.NET application where our users authenticate using client certificates over HTTPS. Our users are only using IE7.
Once a client certificate has been used to authenticate successfully it stays in the browser's SSL cache until the process is closed or the user manually clears the SSL cache. We want to be able to clear the SSL cache whenever a user logs out, or their session expires, to improve the security of the system.
Our clients already use smartcards to access the system, which unload certificates automatically when the card is removed from the client computer, but this does not clear the browser cache at all, leaving a potential avenue of attack from another user who had access to the same machine as the genuine user.
I've found out how to do the actual cache clearing from JavaScript:
document.execCommand("ClearAuthenticationCache");
which works perfectly when a user explicitly logs out, as we can execute the script on the client before allowing the user to log in again.
NOTE: IE7 only lets the cache be cleared programmatically when HTTP Keep-Alives are disabled on the web server.
Here's the tricky bit - if a client's session expires, I don't know of any way to handle this in the browser before the user tries to login again. I can't clear the state when they get to the login page, because I need the state cleared and a new certificate chosen before the page executes on the server.
Any ideas? Apologies for length of question, but background is important for this one.
Never mind, I came up with a good solution:
When the user successfully logs in, we create an additional session cookie that doesn't expire until the browser is closed.
If the user comes back to the login page later and the request is unauthenticated, we check for the existence of the session cookie - if it exists, we know that the user has previously had a session, so we explicitly log them out, exactly as we do for the user-initiated logout. If the session cookie doesn't exist then we attempt to automatically log the user in using their certificate.
The custom session cookie is deleted for each explicit log out, and re-populated for each successful login.
This gives us the best experience for the user, and guarantees that a certificate will be cached only as long as a session is still valid (15 minutes, sliding). Also, the session cookie cannot be removed by the user so there is no way to bypass this behaviour. They can't use the site without accepting session cookies either.