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.
Related
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.
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 incorporating Google Sign-In for my website and the basic setup is working fine, however I face a problem to manage the user's login status.
I came across the below SO question, which suggested to use sessionStorage/localStorage to carry the login status across pages of a website, and when user signs out the stored info should be cleared.
https://stackoverflow.com/a/40206395/5345604
I afraid I don't entirely understand the suggested implementation though. What if user signs out from his Google account somewhere else, say from Gmail or from Google Maps? In this case when the user revisits my website, how can I detect that he is no longer signed in with Google and remove the stored client side session? Or this is not the way it is supposed to work?
And on top of the above question, I'm also thinking about the authentication with my backend (PHP). Given the ID token, shall I be sending it across to my server and authenticate it with the Google API Client Library every time? Or shall I only authenticate the user once and store a flag of indication in $_SESSION, and then destroy the session when the user signs out? (Given that the token is in fact a JWT, I suppose the implementation is meant to be stateless and requires the token to be passed to the server every time? Are there any concerns to implement it with the traditional approach of a server side session?)
I can only answer your first question: The login of your website is completely separate from the login status of other Google services. Even YouTube is separate from google.com.
I'm building my own IMAP client using node-imap, and I'm testing it against accounts on office365.
Since it's under development, I tend to hammer on the IMAP server more that I would in production, but not necessarily what I would consider to be too much.
Occasionally, I start getting the IMAP response "BAD User is authenticated but not connected". This comes after the first command after a successful login.
This is not related to password changes as other similar articles indicate, as my passwords are not changing during this time.
When this happens, the account seems to get locked up for a period of time. I seem to be able to jiggle it free by disabling then re-enabling IMAP on the account via the office365 admin panel.
So it looks like there's a circuit breaker of some sort in the IMAP interface on office365. Microsoft documents a limit of 20 concurrent sessions. In my case I am only opening one session at a time, but I am then closing it and re-opening it again soon after (debugging), so if I am running afoul of a limitation, it's not documented anywhere i have read.
Microsoft support has been helpful but unable to help me root cause this.
In order to take this app to production, I need to know what causes this to happen.
Has anyone else had a similar experience with office365?
You may want to take a look at the Outlook REST APIs rather than IMAP. The REST APIs are the recommended development API for Office 365 and are much better suited for app development with features like webhook based notifications, and are constantly evolving with the new features and functionality in the service. They also don't have the session oriented nature that IMAP has that results in the kinds of problems you are hitting.
There is a NodeJS quickstart guide to O365 here: https://dev.outlook.com/RestGettingStarted/Tutorial/node
you need to perform 2 operations on exchange online using powershell
You need to create the service principal
New-ServicePrincipal -AppId {clientid} -ServiceId {enterprise application objectid} -Organization {tenantid}
you need to grant your service principal access to the mailbox,
If the principal does not have the access, you get "user not connected"
Add-MailboxPermission -Identity {email} -User -ServiceId {enterprise application objectid} -AccessRights FullAccess
See "Register service principals in Exchange" at
https://learn.microsoft.com/en-us/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth
If you have already verified that your password is correct (by logging into your mailbox from the web) then the issue might be Exchange server keeping a list of all your active login sessions.
Try signing out from all other locations by clicking "sign out everywhere" on the account security page https://mysignins.microsoft.com/security-info and then retry signing in again.
Office365 will accept connections and successfully authenticate even when the user doesn't have permissions to access the server by IMAP, and this is the exact error it gives in that situation.
To resolve it, go into the Office365 panel, open the user, and ensure that the IMAP permission is checked.
I have developed a multi-page Javascript web application. My clients have asked me to provide a login page. They do not need anything fancy and requested a single username and password that they can share with those who need access to certain featured within the application. They want anybody to be able to see the application, but only authenticated users can use certain tools within the application.
I currently use an ASP.net proxy page (.ashx file) for handling requests to and from a 3rd party server storing the data consumed in my application.
I've never created a login system and have no idea where to begin. I don't think I need a database for login information because there will only be one username and password.
How could I go about securely storing the username and password to authenticate with the user-submitted login information and enabling parts of the application based on whether a user is authenticated or not?
The good news are that you don't need to build the login system, Microsoft did it for you. This is called the Membership System. All you need to do is expose this API to your end users.
And it's a bad idea to have a single credential for everybody. It is better to assign unique credentials to each user.