I'm loving working with Firebase but I have hit a brick wall.
I can authenticate in Firebase using a provider but it doesn't matter who they are, once they provide there credentials they have access to my application.
I want to restrict which users can access my site.
I am assuming the best way to do this is via security rules but I haven't seen a great example of how to do this.
Are Custom Tokens the best way to do this?
How do I associate a custom token to a provider user?
Is there a better way?
If possible, could someone point me to a resource that clearly demostrates this or provide an example?
I have read the links provided from this post but I can't see any example that grants privileges to certain provider users.
Related
I have the following mobile app scenario based on a Firebase backend:
Two or more mobile app instances communicate with each other through a central service (trusted). The apps are paired by exchanging a shared secret, e.g. through scanning a QR code or entering a pairing code.
Users are anonymous, ie no signup required (or possible). Essentially, it is the specific app on a specific device that is paired with a ditto counterpart (vs user-to-user).
Information exchanged is sensitive but has no intrinsic value: It must be possible to trust that information comes from a given device and it must be possible to trust that the information has reached the intended device and not an impersonating device. But it is not a critical problem that an app instance's information is lost, e.g. if the app is removed or the device is destroyed (an annoyance that requires re-pairing, but not a critical issue).
It seems Firebase Anonymous Auth is a perfect match for this scenario - but the documentation hints that it should only be used as a temporary solution until users create an actual account. Are there any drawbacks to using anonymous auth as the sole authentication method for the solution? The alternatives I see are some kind of hack using a custom token-based login or perhaps email/password auth.
Are there any drawbacks to using anonymous auth as the sole authentication method for the solution?
There isn't unless the user uninstalls the app.
The documentation hints that it should only be used as a temporary solution until users create an actual account.
Why a temporary solution? It's because anonymous accounts do not persist across application uninstalls. If a user uninstalls the app, everything that was saved locally will be deleted, including the anonymous auth token that identifies that account. Unfortunately, there is no way to reclaim that token for the user.
The alternatives I see are some kind of hack using a custom token-based login or perhaps email/password auth.
IMHO, the best approach would be to use anonymous authentication but to also let the user the possibility to link their account with email and password or any other providers, like Google, Facebook, Instagram, and so on.
I'm developing my project and here is a deal: I'm having firebase auth email and password based. Then I've created landing for users and what I'm trying is to let users signup from landing which is on different domain and stayed logged in on my main app.
I've looked up firebase docs but didn't find any snippets. Basically I think there should be auth provider config, but again there is no info. Maybe you've faced such an issue, how you've solved it?
You cannot signup users on one domain and allow them to login into a different domain with those signup credentials. Firebase doesn't allow that. Each domain has its own auth setup that doesn't coincide with another domain's authentication. You can use sub domains if you want. ->
https://dev.to/johncarroll/how-to-share-firebase-authentication-across-subdomains-1ka8
You will have to create cloud functions but to achieve this even on subdomains.
Gist of that article.
Getting Firebase Authentication to work across subdomains is not super
straightforward, but it is doable without that much work.
Unfortunately, you need to be familiar with a number of concepts such
as CORS, cookies, JWTs, Firebase Authentication itself, etc.
Might as well develop your own Nodejs server instead of using hacks and workarounds like in the article.
I currently built a small WebApp for personal use. I want to push it online but not everyone should have access to it. I want to send the password to people which I will allow to access the site but I only want one password which can everyone use. I build the App with just Nuxt.js and firestore because I'm not familiar with backend technology.
I'm aware of the firebase authentication, but it only supports authentication with e-mail address.
Does someone know a simple Method how I can do this? Security is in this case not very import, I just want that not everyone can go on the site yet.
Thank you very much for your help.
As you mentioned, you're aware of firebase authentication, create a single account with email and password. For now, on login screen you can pass email hardcoded in input[type='hidden'] field.
You can use basic authentication for that. Not the most secure way of securing a site since the credentials are sent over with each request but If your site is under https you should be fine.
My client has a request that he wants to login to ASP.net web application via Google account. As I have never done something like that I have some concerns.
What bothers me is that he wants to add roles (administrator, user) to specific accounts and this puzzles me because I'm not sure how to connect Google account data with my database. I assume that I won't be able to get the password or username that I could store to my own database.
Where to start?
Use OpenID. This is implemented in ASP.NET in the DotNetOpenAuth library. It includes samples for Google logins, and it's very easy.
The roles should work to. As you build up your user table, just add users to the appropriate roles.
Have a look at this:
http://www.asp.net/vnext/overview/aspnet/oauth-in-the-default-aspnet-45-templates
Scott Hanselman giving a quick overview of the OpenID features in .NET4.5. This might be a good starting point for you.
On MSDN:
http://blogs.msdn.com/b/webdev/archive/2012/08/15/oauth-openid-support-for-webforms-mvc-and-webpages.aspx
I suggest you to take a look at this codeplex miniproject : http://loginwithgoogle.codeplex.com/.
You might find it helpful.
Regards
I must be stupid, because all the articles I've seen on OpenID in ASP.NET have simply confused me on the issue. I'm pretty sure I understand the concepts involved here, I'm just a little fuzzy on how things look on the back end side of things.
So a new user comes to my website and wants to create an account. Here comes the flood of questions:
Is the first step here to have him pick which openID provider he will use to sign in?
Do I prompt him for a user name on my system?
Do I need to tie him to the same openID provider each time he returns, or can he select a new provider each time?
What does the database look like here? Do I have his username in a table and that is linked to an openID provider?
What if the user doesn't have an OpenID account? Should I allow him to create a traditional account on my end, then expose myself as an OpenID provider?
What am I missing here? I'm usually pretty bright, but this area has been like kryptonite to Superman for my developer smarts. Thanks in advance!
Adam
This page is a step-by-step tutorial on implementing OpenId on a web site. I believe it will answer all your questions about the mechanics of adding it.
A Recipe for OpenID-Enabling Your Site
If the user doesn't have an OpenId I would just allow them to register 'normally', storing their credentials for local use. There is no need to add the extra complexity of becoming an OpenID provider unless you have a business case for that.
Dude, you're not alone. OpenID confuses everyone except the people who designed it, and even then, I'm not so sure it doesn't confuse them either since there are multiple OpenID providers and slight incompatibilities between them, depending on whose libraries you use.
Imagine the user is a sql "table" himself (that table contains his "credentials"), and you have a table of profile data specific to your website that you own. The OpenID url is a "foreign key" that you use to "join" these two tables. You must prove to yourself that he really owns that OpenID url before accepting it (or associating it with your private profile data). You're essentially "offshoring" the authentication portion of your site.
So ultimately, you use an openid client library that does the work for you on your website. They register as normal filling in "full name, "age," etc (whatever you want) but they provide an openid url instead of username/password. The library looks after verifying they really own it. You have to trust this library to do that. You then store all of your profile data with that openid. Done.
While you could offer your own openid provider, it's not worth it at this point. There are plenty out there already. What you could do though, is offer a traditional username/password INSTEAD of openid. The idea of openid is that your register ONCE with a provider, and then just prove you own that URL to any site that wants to use it to identify you (instead of username/password).
Make sense?
-Oisin