I have developed several web applications with the own login forms/logic etc. I would like to simplify these by creating a single dedicated web app to handle all the login logic using FirebaseUI. The way I imagine this working is when the user needs to login with one of my apps they are redirected to my login web app. The user supplies their credentials and if successful the login app redirects back to the original app with data to confirm whether the login was successful.
If this is possible I shouldn't have to repeat the login logic in my other web applications and any changes to login code are only required in my login app. I'm not sure if such an approach is possible, however, or how I could securely and safely let each web app determine that the user has successfully logged in. Can anyone offer advice on how to implement this or point to examples where this has been done already?
You might be looking for single sign-on.
Google does something similar. Every time you login you're redirected to accounts.google.com, and after that you're redirected to your app.
You're right in saying that it's trickier than it appears on first sight though. Most web login systems are based around cookies and the whole client-server process around them. Cookies are set per domain. If all your webapps are on the same domain or subdomains of a single domain, you should be OK to go with this approach and get the results you want. If not, you're going to need some extra work to get code from different domains to speak with each other and make everything possible.
In general, if designing a login system from scratch is considered a big endevour, designing a single sign-on system is an order of magnitude harder. OWASP had this to say about them in 2011.
Related
I hope you are doing well!
We are working on a project that consists of 3 projects/websites. It's basically something like a Management Platform for the resources, a Platform to display information and updates, and a Platform to manage both those platforms. (Something like Office365 and PowerPoint, Word, Excel where Office365 is the main application between them).
In our project, we want to integrate a navigation drawer in which the user can navigate to the different application from our 3 websites without having to re-login. In this case it would be easy. However, would there be a way that if the user access the other website from the browser (ex:"www.exameplwebsite.website2.com") we login the user directly if he was already logged in to a previous application from ours?
We thought about local storage however the local storage and cookies accessible depend on the domain we are accessing.
Is there a way to make this happen? Or would using a navigation drawer the only way possible?
(For context we will be using ReactJS)
I think it wouldn't be that hard with JSON Web Token (JWT) for authentication. When you redirect the user from one site to the other do it with a post request and include a JWT token in it. The new site can capture that token and send the token to the browser and the browser can catch it and saves it into its own localstorage.
I can think of two solutions ->
Use micro frontends (Recommended)
If all three apps have different domain names (app1.com, app2.com, app3.com) then you're right you cannot share any token using cookies and local storage.
Here, You can take the login/signup pages and the navigation drawer into one parent app and load all your other apps using micro frontends.
Use SSO
SAML and OIDC are made for this specific purpose but this is a very complex topic. Basically, your users will need to log in once(at someplace like google or OneLogin or your own identity server)
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 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.
Quick short background
I'm building a standalone web app using Angular JS 1.5. This web app makes usage of a API built with Laravel 5.2 (no sessions, just JWT Tokens and REST calls). Using Laravel-Socialite, I managed to make the following structure. It works nice and all, but we kind of have a overload of redirects.
The Button calls a /facebook route that invokes the Socialite magic box which leads to redirect to the Facebook Page for authorization.
After I achieved this, I noticed that a Facebook Login LOOKS a lot more of a front-end task than a back-end one. It's just about helping the user quickly sign up using Facebok available data or sign in without a password.
The Problem
Socialite makes usage of my Facebook App Secret, not to mention that it's a known environment server operation, while a Front-end we may never trust. Here is what I managed to achieve using JavaScript SDK (with AngularJS).
On a first-time access, I can get that information and sign up the user and automatically sign him in. But the problem lies on a existing user.
In this case, technically I can use the response.email information that Facebook gave me and make a request to my API to make a login without a password. But can I really do it? How do I make sure the request is being made because Facebook authorized it? After Facebook replies to my Web App, what is a secure way to tell my server that it can issue a JWT Token to that email?
Conclusion
Do I make the three-step redirection (Web App → Server API → Facebook) to sign in / authenticate a user using Facebook or is there something I'm missing here that could be the key to transferring this responsibility to the front-end (and avoiding a 3-step-redirection)?
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.