We Keep Coding

Firebase allows creation of users via the JS SDK without being authenticated

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

Stripe Connect | Account id safe to expose?

I have a current setup with Stripe and Laravel as a backend. Everything is working perfectly and as expected but I have a question regarding security.
As I have a React frontend to take payments, I am using the package #stripe/react-stripe-js which is Stripes official package.
With the package you obviously have to load in Stripe and pass in you public key and in this scenario the connected accounts id. I've done this thus far, but the frontend uses a API call to see what the order is and the price etc, with that call sits the connected accounts id so I can append it into the load stripe method.
const stripePromise = loadStripe(
'xxxxx',
{
stripeAccount: 'xxxxx',
}
)
As this has to return in plain text so Stripe can read it, I wanted to know other peoples opinions on whether or not this is safe to expose the connected accounts id.
I can't really see any other way around it, I could encrypt / decrypt somehow but even still, that's accessible to the client side version so it is still visible.
I've read the Stripe documentation which can be found here https://stripe.com/docs/connect/authentication#adding-the-connected-account-id-to-a-client-side-application and it seems as though they hold it in plain text.
With all this mentioned, the secret key is obviously never exposed to the frontend and all of that creating the Payment Intent is handled in the backend.

Yes, it is fine to keep the Connect account ID public.
A Stripe account ID (e.g. acct_123) is intended to be used client-side as well as server-side, with your respective Stripe API keys.
The Account ID will only work if your Platform is "connected" to that existing Stripe account, otherwise the account ID is useless if used with an unrelated Platform's API key (the Stripe API validates that and returns an error).

OAuth Login Flow: How to create users on my own backend?

We have a web app that caters to a small set of users that are guaranteed to have an account on Office 365.
To save them from remembering one more password, and to use Microsoft's infrastructure for OAuth, we decided to allow them to login using their Outlook credentials.
It is a react app, we are using the msal library and we have successfully been able to receive the accessToken from Microsoft. (Thus, authenticating the user's identity.)
What I am not confused about now is what I should do with that token:
I need to have my own User database. What information should I store in it? Should I store the access_token as well?
How do I verify the user's identity on my backend server?
Basically, what is the ideal way of managing this kind of a scenario? Wherein a third party authenticator is used (and solely) used to confirm the identity of the user and get the name, profile image and other things only.
Any references to existing workflows or an explanation of the steps involved will be highly appreciated.

How to authenticate user in browser using AWS Cognito?

I need to authenticate users in browser (not mobile app) using AWS Cognito with username/pass, not FB/google IdProviders.
There are a lot of docs but they seem to be separate blocks which either incomplete, do not fit the requirements or do not fit each others :(
I created Cognito User Pool, then Identity pool and tied the userPool to the idPool, then I stuck. Do not know which library to use and how to use it.
The closest I find are:
https://aws.amazon.com/sdk-for-browser/ but my experience is not enough to convert their FB samples to not-using FB
https://github.com/aws/aws-amplify but using this lib I'll have to study React/Angular from the very beginning (I'm not a front-end developer, sorry) and I have no clue how to convert their npm-based samples to front-end javascript (npm is for NodeJS thus back-end, isn't it?).
All I need is plain html form with username/pass, send the request to Cognito and a way to check during the next page load whether the password was correct. If it matters I will use AWS Lambda as back-end for processing future tasks.
How can I do it? Is there a tutorial/doc for my case?
Thank you.

You can use AWS Cognito UserPools Hosted UI for your use case. The simplest form of authentication is using the Implicit Grant.
For more information about setting up Hosted UI refer Add an App to Enable the Hosted Web UI.. This will create a UserPool where users can register them self (If you plan to restrict this, you will need to either add users using the AWS Web Console, Cognito UserPools or using their SDK)
The steps are as follows.
Set up Cognito Hosted UI and register your application domain. This will create the login/registration pages for you where each of this will have a unique URL. What you have to do is, if the user is not authenticated (Let's discuss how to detect it later), you need to redirect the user to the Login page.
In the Login URL, you also need to specify the redirect back URL to the application so that after a successful login, Cognito will redirect back the user to the application providing the token in a query string.
You can then access the id_token from inside the application and use it for querying the backend.
Since the id_token is a JWT token you can verify it at your Backend using the public key available at the Cognito token endpoint.
To implement the JWT verification, you can also refer Cognito JWT Token validator NodeJS module.
Note: If you need to keep the user's logged in for a longer time period (Than 1 hr), you might need to use the Code Grant flow which will return a Refresh Token, which could be used to retrieve new id_tokens programmatically.

Building an HTML Widget to embed paid content - how to secure communication with the backend?

I'm creating a widget that shows content when the page visitor pays for it. I'm handling the payment form inside the widget and I'm using Stripe for credit card handling, charges, etc.
My problem is: I want to make it easy for the user to pay for the content, right now, I'm my working proof of concept I only ask for the email, then:
Check if I already have this email on my system, check with my API server if it has a payment for this product associated and then let the user get to the content.
If the email is not present in the system, it is created, and return only the Stripe publishable key.
If the email is present, but it has no payment associated with this product, simply return the Stripe publishable key.
When the widget gets the Stripe key, then it shows the payment (credit card) form, which is used to get the Stripe token, and this token, along with the email, is sent back to my API server. If everything is Ok, then the widget retrieves the content and shows it to the user.
Now, the question(s): How to secure the communication between the widget and the server, besides using HTTPS? I already have support for application id/secret pairs, how can I use them to to authenticate the requests from the widget to the server? The widget will be inserted in pages on arbitrary domains, so using the Referer/Origin headers is out of the question.
I don't think that is really important, but if it helps, I'm using Django 1.7 and Django Rest Framework 3.0.5.
Thanks!

There is an api you can use, called CoinTent. Its sub-motto is "Purchase individual pieces of content for small prices with one account and one click." HEAD HEAD HEAD HEAD...