I am wondering if firebase function getAuth() somehow checks if the the website link to which the token was initially issued is the one that is requesting for the authorization status.
I am concerned that if a malicious website somehow had access to my Firebase.io link, and runs a simple getAuth() in the same browser as my Firebase based backend website, it will be able to access the Firebase token issued to the user of my website.
Any thoughts on it would be greatly appreciated.
Note: I work at Firebase
Firebase Authentication sessions are stored using LocalStorage accessible only to your domain. This means that the sessions are not accessible from domains outside of your control.
If you're using OAuth (Google, Facebook, Twitter, or GitHub login), then authentication is further restricted to your domain via our OAuth configuration in your Firebase dashboard, where you must explicitly authorize domains for access.
Users of email / password authentication can authenticate from any source, provided that the user has access to the password. In short, we ensure that the sessions stored for your domain are not accessible elsewhere. Our top priorities for this product are data security and making that security available to you (as the developer) easily and as the default.
If you have additional concerns that are sensitive for any reason, don't hesitate to reach out to me rob at firebase.com.
Related
I am currently working on a React-Native project with my own backend
I have to use OAuth2, but I want to have the user enter their name and password and not forward them to Facebook / Google, for example
Any help?
The only grant types that allow acquiring tokens without redirects are the client_credentials and the password (resource owner password grant). Both of them are only feasible if you are running your own Identity Server (like Keycloak).
For identity federation with external systems, you will always need a flow that redirects the end user (at the very least in an iframe). The user authenticates against Google, not against your system. Google then issues a Token, and your application can verify the token was issued by Google. A system without a redirect would be equal to each and every user giving you their Google password.
This is the kind of thing that OAuth2 was designed to prevent, and so it is not possible.
When using OAuth2 against Google (or actually any external provider), how is it possible to verify that the user is still logged in to their Google account on the browser and their user is in good standing?
I don't want disabled users to access the system after they have been disabled, and to make sure that the web app cannot be accessed by anyone using my browser after I logged out of Google without having to delete a bunch of cookies for each site.
Is this even possible?
I explored querying the user ID with the users API but it requires authentication to make the query, and the anonymous API does not work for users without a Google+ account (or at least, not that I could find).
In addition, the users API will not help if the user logged off.
I'm using node.js with express.js and passport.js for authentication, with a cookie session.
Does github (twitter, stripe & co) uses OAuth for its own signin/signup forms?
All those authentications are cookie based, so is this regular web client basic auth or does it use some form of OAuth or xAuth ?
On login, a call to https://github.com/session (or https://twitter.com/sessions or https://dashboard.stripe.com/ajax/sessions) is made (with credentials given as formdata) that result in a 302 (or 200 for stripe) with Set-Cookie and a location to https://github.com (or https://twitter.com).
It does not seems that they use a client_id to get a code and exchange it with a token. All the OAuth dance seems striped. And the Bearer header too. So, what's going on here?
Thanks.
OAuth is a three-legged system, two-legs is sort of useless. The whole point of using OAuth is to give other services the ability to perform actions as you without needing to specifically authenticate or pass the data yourself. In the end you must still authenticate against some Auth service.
Since you are using these services as the Authentication mechanism for other sites, it wouldn't make sense to attempt to use it in your own. As part of setting OAuth, the second site redirects to the first and asked to authenticate there, which means you literally need to enter your credentials. Which means that if you are okay entering your credentials into say github, having a different authentication mechanism is useless.
OAuth allows non-github to create user accounts by trusting github with the authentication, or it allows non-github sites to make changes to github as the user once the user agrees to the interaction by logging into github to accept that policy (logging in using their credentials).
Sign in forms on github (and others websites as well) are simply cookie based.
Usually every direct login via the website through a browser is made with cookie based system , simply because isn't necessary to do otherwise.
A bit of theory
Every time you use a login form in a website you are calling an API, not necessarily intended for public use (so a private API)
When you put your credentials in the login form and push that login button , your credentials are being managed by some code in the server that permits you to authenticate against that website.
There is no need for the entire OAuth overhead here because the website has full control on the authentication mechanism and isn't necessary to externalize.
Why OAuth is different in this contest?
OAuth is a system designed to distribute the authentication system across different services / applications even from different vendors.
In OAuth there are multiple actors involved:
the client
the authorization server
the resource provider
In your case all these 3 actors are the website itself and so there is no need for a decoupling system like OAuth.
I want to integrate google calendar and analytics from our website's google account in our website's content management system.
So our cms has access to the calendar and analytics without requesting the users to log in.
I'm confused by the documentation that always talk about redirecting, logging in and granting permission with your personal google account.
Could someone point me into the right direction, thanks.
OAuth is a mechanism which allows other applications access to another application's protected resources. In your case, your website wants to access protected resources of a Google account. OAuth does this in multiple steps, but the steps can be summarized as follows:
Your application sends a request to access certain specific protected resources to the OAuth server (which in your case would be Google). At this point you transfer control to the OAuth server; in other words, you are redirecting to the OAuth server.
The OAuth server then shows a page in which it shows to the user a list of the resources that are being requested. The user then has the option to allow the application (which initiated the redirection to the OAuth server) access to the listed resources, or not.
If the user chose not to grant the application access to the listed resources, the workflow ends.
If the user does allow access to listed resources, the OAuth server redirects back to the application, sending an OAuth token along with the redirect.
Once control has been transferred back to the application, it extracts the token from the request. Remember, this token was issued by the OAuth server.
The application can now access the requested protected resources on the OAuth server by sending the token with each request. The OAuth server will recognize the token it just issued and return the protected resource being requested.
A nice page where this workflow is described is: http://hueniverse.com/2007/10/beginners-guide-to-oauth-part-ii-protocol-workflow/
Of course, you should also look into Google's OAuth documentation. They even have a nice OAuth playground where you can play with the OAuth functionality Google offers.
We are developing an SPA - full client base javascript application and need to authenticate our users to get access to the internals.
As I found from the search we can outsource our authentication mechanism and use Google accounts for that. I learned from this site
https://developers.google.com/accounts/docs/OAuth2Login -
How to deal with Google API and mechanism for authentication.
In the short word, we need:
send request to google url with params to ask user to allow SPA use their personal data
in case of success we get a token from Google
we may use this token to get access to API we were asked and work with it.
This is described well and I understand it and have some JS code to make it happen.
What I do not understand.
I have an application with it's private data. I want use user's e-mail as the login, or user id (doesn't matter how to call it) to access app's internals, such as user's created tasks, user's profile, etc. So, to display user's created tasks in my SPA I need query database with the user's e-mail.
I imagine the next scenario:
user click Login with Google button
we obtain an token - this means user was authenticated successfully
we persist user and his e-mail to work with SPA
when user click Logout we clear all access data
Where should I persist this data?
In case of Forms Authentication I understand that we pass login/password to server and if they match the database we create Forms Ticket and store it in cookie.
Is there any similar case with Google's auth? If I'll store user's email in cookie I think that's not very good from security reason. If I'll save a token - I'm not sure why I need it and how to use it in my SPA, I'm not using any Google API after authentication.
Do you have any example case how do we build our process in similar cases?
Thank you.
If all you need is the user's email address, then you would be better off using OpenID instead of OAuth. OAuth provides access to a user's account and services, scoped to a specific resource or set of resources. OpendID is designed just for logging into a third-party service. You can then extract the user's ID and email address from the OpenID login. Note: The ID will always be sent but the email address has to be explicitly requested during authentication.
Google also supports a hybrid OpenID+OAuth scheme that lets you piggyback OAuth requests on top of an OpenID login if there is some resource you need to authenticate to. Take a look at the authentication document to get an idea of how both protocols work and which is better for your scenario.
Once you have the email address returned, you probably shouldn't persist it in a cookie. The normally recommended way to handle it is to add it as a session parameter. That way only the session cookie is stored on the client, and the server can use it find the values it needs. This answer has a good explanation of the differences and when you want to use sessions versus cookies.