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
Related
I'm currently trying to dev a website allowing people to buy things that are available on the web site by using tokens from our project. (so it's just about sending tokens, not a trade between tokens and a NFT).
I've done almost everything needed, and everything works using SOL. Now i want to switch the payements to our own custom token.
I've digged every posts on this forum and tried all of them but still couldn't find something working for me.
The problem is that all those answers use a hardcoded private key or the Wallet Interface which requires a Signer (keypair). Since our users will log on the site thanks to phantom it's not possible for us to get that secret key. Have you got any idea on how to implement that custom token payement?
Thanks in advance.
Checkout the solana wallet adapter https://github.com/solana-labs/wallet-adapter you can use the wallet object to sign your transactions. They have an example in the readme to transfer SOL, transferring an spl-token is very similar, i often use https://github.com/solstar-tech/easy-spl which works well together with the adapter.
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
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.
I'm working on an Android app in react-native and the app communicates with an API I'm working on for the app. The API is built with Laravel and Laravel Passport.
I know that Android apps can be decompiled so any secret keys stored within the app could be easily found. This is the reason for my current approach.
You can only gain an access code during registration. The application uses anonymous accounts so if you lose the access token, it's too bad. The app makes an API request to /api/register which creates the account and returns an access token. The app would store the token and use it to make further API requests.
The problem is that the registration route does not use any client secrets or access tokens. It is very easy to automate requests to the route and create an army of bots. I could potentially limit the amount of requests like a lot of API providers do but that wouldn't stop the issue.
I've heard about payload hashing but this usually requires a salt that is in both the app and api. Again, this is not secure and couldn't someone just hash it themselves if they know the salt to spam requests? Maybe I'm misunderstanding how payload hashes work.
Hopefully someone can assist.
You'll probably want to use something to detect the user agent hitting the route. This package has a lot of useful features:jenssegers/agent. For example, it offers crawler detection:
$agent->isRobot();
Depending on your hosting provider, you may have access to tools that automatically blacklists ip addresses after X number of requests per minute (or other metrics). I know AWS offers this service.
Another option is antonioribeiro/firewall. Track users based on ip or geography and redirect/block accordingly.
I'm at this junction at the moment and the route I'm taking is one where the user is challenged to solve a simple puzzle:
registration process on app/web picks up a challenge from my registration server
the challenge is shown to the user with the input fields: email/username, password and the answer input for the challenge
it all gets sent to the registration server and if the answer is incorrect, the registration is denied
This "are you human" challenge is what will stop bot-registration so it needs to be a little smarter than the one coding the bots, so a selection of various challenges on the server would be nice.
I'm thinking of "select the n-th value from the dropdown", "select the first/last option", "write the color 'blue'" or "what whole number is between 3 and 5", and so on, for which variables can easily be generated by the server, the challenge and answer input can easily be created by the registration script, and it's easy and not very time consuming for the user to solve.
Another option I'll explore is to throttle requests by IP, combined with black-and white-listing those.
I'm working on a PhoneGap project using Ionic. It's basically a chat app, so I need the user to be able to register, login and send messages using a backend API on my server. Naturally this needs to be secure, so I'm wondering what the best way to securely communicate with an API endpoint is, when using a AngularJS and PhoneGap.
Ideally, it should not require a server cert, as currently I don't have the funds to purchase one. In previous projects, I used a method where each account was assigned an ID, and a hash consisting of a secret + their ID, which had to be included with each request to ensure that the user couldn't forge requests from another ID, however I don't know how secure this method is.
Any tips, suggestions or read material would be really appreciated. I understand this question sounds subjective, so if possible please answer based on facts, security disclosures and any documentation on methods.
I know the solution to all your needs and it is called Firebase.
How your requirements will be met by firebase:
1. You are using Ionic to build your hybrid app(you are cool!) and that means AngularJS.. Firebase has the perfect library called AngularFire, that uses AngularJS to interact with the firebase servers.
You are building a chat app, awesome! Firebase has real time syncing between your app and database. That is a lot of work saved for you by Firebase (Claps).
You need to register users, Firebase has super easy user register management(both OAuth and manual registration)
Security! It is super important and Firebase has you covered even here. Implementing user level security is super simple using some simple json format security rules. I will quote this from the site "The safety and security of your data is our top priority. Firebase requires 2048-bit SSL encryption for all data transfer and allows you to restrict reading and writing via granular access controls and custom authentication.
All data is replicated and backed up to multiple secure locations."
It is free(upto some level. Do some research about it, I am not sure).
Your basic id + hash security measure is not bad at the same time not perfect or dependable. Firebase has you covered here through simple login and read/write rules and as well as some closed sourced security.