I found out that it is possible to create a new user in Firebase using the JS SDK without any user being logged in using the method createUserWithEmailAndPassword. For consumer apps i can image this is a great feature so that a "new customer" can create an account.
However, for the b2b world this ain't such a great feature and in my case we actually wan't to disable this.
Is there any configuration possible in Firebase or GCP that disallows any random person in the world to create an account in my environment?
Thanks!
If you want to disallow the creation of new accounts entirely, then you probably don't want the normal Firebase Auth standard email/password auth at all (which does not have the ability to disable new accounts created by an end user). You probably want to use custom authentication, and control precisely how signups occur with your own backend. You can control everything that happens on your own backend, of course. The downside is that you have to control everything on your backend!
You can't disable account creation but you can make your system only work with account you created with custom claims. You can make a cloud function to add a specific claim to your accounts, then delete that function. Now, with security rules like
allow read, write: if request.auth.token.yourClaim == true;
effectively, any account created without the claim can't do anything in your system. I think this is easier than implementing your own authentication scheme
Related
What is the difference between using Google OAuth and signing in users at the frontend of the application, and signing in users at the backend side of the application?
Example: Signing in users and getting the ID and a auth object in React or letting Node/Express handle everything, the prosess, redirecting and store it in a database.
Is there any advantages for one or the other methods, which are most common and are there any "rules"?
What is the difference between using Google OAuth and signing in users
at the frontend of the application, and signing in users at the
backend side of the application?
So to clarify to everyone reading this, signing in users at the backend side of the application is another way of saying OAuth for servers and signing in users at the frontend of the application is OAuth for JavaScript browser applications such as React.
Signing in users via OAuth for servers and browsers results in a 'token' that a server/browser can use to make requests on behalf of the user. We are asking the user to provide us access to their information via an outside service provider such as an email address, identification of some sort and it will be inside that token as well as some possible permissions that allow us to take actions on behalf of that user.
Is there any advantages for one or the other methods, which are most
common and are there any "rules"?
Server-side OAuth is usually used when we have an app that needs to access user data when they are not logged in. So if you are attempting to build an application that needs to access the users email every ten minutes and possibly delete emails on the users' behalf, you would want to be able to access their email account every 10 minutes regardless of whether they are logged into our application. So for this use case we want to make use of Oauth for server.
Otherwise, if we are not trying to do anything on behalf of the user except sign them into our app, then we can just go with OAuth for browser.
Those two things are very different. Without knowing the specifics of what you're trying to accomplish, you should know as a general rule that front-end-only authentication and authorization leaves you extremely vulnerable.
If someone knows JavaScript well, or is using editing plugins, or any of a million different things, they can bypass much front-end authorization. Or they could just watch to see what calls your app makes to the back end, then simulate those calls from something like Postman, bypassing your web front end entirely.
If you're not securing your backend, you're not secure. Typically systems do both.
It is just a different ways of registering users to our website.
Signing in users at the frontend using OAuth can be very handy as it enables our users to not go through our boring forms in our website. Using OAuth is just one click away from registering users in our website. Beneficial to both the clients and developer.We are provided with the general information about clients by the provider(google,facebook) just clicking on one button.
Signing in users at the backend side is the traditional way of registering our clients. Here we force our client to fill the forms in our website(which may be painfull if it is a long form) and all the filled data is stored in our database.
So they are both different ways to register clients to our websites. Both are used very often. It depends on usecase and needs. Oauth can be used if you want to attract more clients by registering them just by one click.
Within Office 365 its apparently not possible to assign a security group to a shared mailbox. This means that all users need to manually be added to the shared mailbox, which is a pain.
However, Microsoft Graph appears to offer a way to subscribe to changes to a given group. As a result my thought was to build a simple azure function application that receives a web-hook from Microsoft Graph when someone is added / deleted from a specific group, and promptly adds / removes the user from the list of shared mailboxes.
The problem I'm having is that Microsoft Graph does not appear to have an API call for granting a user access to a shared mailbox; and I haven't been able to find another Microsoft API that will allow it.
The only way I've discovered that can even do this programmaticly is with PowerShell, which requires that I create a user to authenticate rather than granting application access. PowerShell also only has experimental support for Azure Functions right now, and I'm not even sure if Azure Functions supports Exchange Online PowerShell calls or how to install it if needed.
Does anyone know a way to do this with REST calls or JavaScript specifically, or better yet to do it with Microsoft Flow without writing code?
If I don't get any answers on the preferred method soon, I will except a solution on how to do this with an Azure Function or Microsoft Flow and PowerShell.
Instead of an Azure function, you could use Azure automation to create an Azure Runbook that will execute your PowerShell code.
The Runbooks allows you to import modules giving you all the functionality you need to do the Exchange Online PowerShell. It also allows you to store credentials of an Account with the correct level of permissions. (While testing you can use an Exchange Service admin account or a Global admin).
So you could create an Azure AD user, use Exchange RBAC rights to scope it down to only have permissions to what it needs to do for security reasons, then store the creds of that user in the Runbooks credential functionality.
The Runbook can then be executed from a webhook.
A small note, you cannot add a security group, but you can add a mail enabled security group and give it rights. The group can be hidden from the global address list in Exchange and just use some bogus mail address on the .onmicrosoft.com domain of the tenant.
Only thing to note, this method of using groups for permissions does give the user the correct access rights, but, the mailbox will not automatically be added to Outlook.
The reason for this is that Exchange adds an Automapping flag to the object you give access rights on the mailbox. But setting this flag on a group does not recurse and also add the flags on users, so users would need to manually go into Outlook and tell it to open the mailbox.
How to manually test in Office 365
Confirmed to work 03/12/2018
Adding a new mail enabled security group in Office 365.
Creating a new shared mailbox in Office 365.
Adding a user to the mail enabled security group.
Open the OWA logged in with the user you added to the mail enabled security group
Select "Open another Mailbox" and selected my shared mailbox.
This is the easiest way to test if the permissions have carried over. But do mind that in Outlook for desktop, the user manually will need to add the mailbox in the settings page, since the auotmapping flag does not carry over.
Also take note of Exchange Online replication time. At its worst it may take up to 30 minutes for everything to propagate properly, but it usually works within 5 minutes.
I want to be able to sign into multiple accounts at the same time (think of how gmail lets you swap between signed in accounts). Is this possible/supported using Cognito? (I only need to be able to use one at a time)
Further, is there a way that I can give the user a challenge when swapping to another account such as a pin code (dumbing down my use case here).
This whole managed user accounts thing is very different to more traditional apps given that the authentication is no longer done on my server side... except for the challenge. Is it possible to mix the server/non-server based cognito authentication like this?
I'm going serverless with lambda and typescript.
Some guidance on how I could achieve this would be much appreciated
Suppose you have 2 applications and if both of them are authenticated using the same userpool, then I don't see an issue in this. All you need to do is store the access id post authentication in the Application 1 and look its validity before allowing the same user to use Application 2, which in turn is using the same userpool.
I believe that you can achieve the challenge usecase by customizing the userpool workflow using the pre-authentication lambda.
Customizing User Pool Using Lambdas
I need to integrate a Trello API into Support System, but I don't want users see the typical popup saying "Do you want to allow this app?".
So, I need always the same user (me) by default for all connections (GET, POST, PUT, DELETE).
I would like when the user go to the Support System can see, add and update the tasks without do log in and without allow none (on Trello) and use my default user.
Don't mind if the solution is on the client-side or server-side.
Is there any way to make this?
Generate an application key that is set to never expire. Use these credentials to interact with your board/list using server-side php scripts.
Your support system will then use these credentials internally to interact with the API.
As Gadget mentioned, you can use a pre-generated access that never expires. Although it's the token and not the application key that never expires. Trello thise calls the "Authorize Route" (when the user must always confirm is standard OAuth1.)
Trello describes here how to get one of those tokens.
(I would comment this instead, but my reputation is too low.)
EDIT: Here is Trello's description of how to do it with their JavaScript-library
I've read about Firebase and it looks awesome for what I want to do.
I've read about authentication and how based on rules certain logged-in users are authorized to do different stuff. Al good.
However, I'm unsure about another type of security: how do I make sure that only my own site (using client-side javascript) can talk to my firebase-backend? I'm asking because afaik there's no way to prevent anyone from looking up my firebase endpoint from the client-side code (url pointing to my specific firebase backend) and start using that for god knows what.
This is especially worrisome in situations in which I want to open up writes to the anonymous user role. (e.g: some analytics perhaps)
Any help in clearing my mind on this much appreciated.
Update (May 2021): Thanks to the new feature called Firebase App Check, it is now actually possible to limit calls to your backend service to only those requests coming from iOS, Android and Web apps that are registered in your Firebase project.
You'll typically want to combine this with the user authentication based security that Kato describes below, so that you have another shield against abusive users that do use your app.
In my opinion, this isn't so much a question about Firebase's security as a general discussion of the internet architecture as it stands today. Since the web is an open platform, you can't prevent anyone from visiting a URL (including to your Firebase) any more than you can prevent someone from driving past your house in the real world. If you could, a visitor could still lie about the site of origin and there is no way to stop this either.
Secure your data with authentication. Use the Authorized Domains in Forge to prevent CSRF. Put security rules in place to prevent users from doing things they should not. Most data writes you would use a server to prevent can be accomplished with security rules alone.
This is actually one of the finer qualities of Firebase and API services in general. The client is completely isolated and thus easily replaced or extended. As long as you can prove you're allowed in, and follow the rules, where you call in from is unimportant.
Regarding anonymous access, if you could make them visit only from your site, that still won't stop malicious writes (I can open my JavaScript debugger and write as many times as I want while sitting on your site). Instead, place tight security rules on the format, content, and length of data writable by anonymous users, or save yourself some time and find an existing service to handle your analytics for you, like the ubiquitous Google Analytics.
You can, of course, use a server as an intermediary as you would with any data store. This is useful for some advanced kinds of logic that can't be enforced by security rules or trusted to an authenticated user (like advanced game mechanics). But even if you hide Firebase (or any database or service) behind a server to prevent access, the server will still have an API and still face all the same challenges of identifying clients' origins, as long as it's on the web.
Another alternative to anonymous access is to use custom login, which would allow a server to create its own Firebase access tokens (a user wouldn't necessarily have to authenticate for this; the signing of the tokens is completely up to you). This is advantageous because, if the anonymous user misbehaves, the access token can then be revoked (by storing a value in Firebase which is used by the security rules to enforce access).
UPDATE
Firebase now has anonymous authentication built into simple login, no need to use custom login for common use cases here.