I am working on a project where we integrating the google openIdConnect to let user sign-in to the application using google auth. I taken help from https://developers.google.com/identity/protocols/OpenIDConnect to authenticate user.
I also need to allow user to reset the password within the application post user logged in. But not able to found any specific help on this.
Can we able to reset password using openIDConnect or it not possible at all. If its possible then how.
NOTE: My preference would be client side solution then a server side.
One of great side effects of OpenID Connect is that you do not need to care about user registration+confirmation and password reset processes within your application. If you are using google as an identity provider, google takes care of this.
At most, you could link to password-reset URL from google, but:
It is already linked on the google's login page.
Google could change URL without prio notice as it is not a part of OpenID Connect specification.
Why do you think google will be using passwords for authentication?
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.
I have been looking for an open google api to get google authentication token by using a user's google username and password. I have came across google-auth node package. And according to it, I first need to log in to create a project in google developer console and then use the key to access the information.
But I want to know whether there is any open api where I can directly pass the username and password, without creating any project in google developer console. And get the authentication token as part of response.
This is my first project using google apis, so if it sounds naive please let me know the right way of authenticating a google account user using a node project.
Sorry, I can't provide any code, as I am stuck at understanding the initial part itself, about how to authenticate different users.
Thanks in advance
You can't use google or any social login, without first creating a project and using it's api key.
That is just how oAuth is designed.
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 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.
I want users to be able to register on my mobile (web based) app and login using their Facebook account. Is this possible using the JavaScript API?
The user can login using Facebook, and the userID and auth code of that user can be sent to my server to create the account, but I see a security flaw because then anyone could then log in as anyone by sending a userID and their own auth code. So can user accounts not be done with the JavaScript API and only with a server side API?
All Facebook requests are also signed with a secret key that belongs to the app you've registered to handle Facebook sign-ups on your website, so you can use that to verify it comes from Facebook and not someone else.
This is also outlined in the registration documentation
Strictly speaking, it is not possible for the Facebook SDKs to explicitly create a new user. However, when you implement a 'Login with Facebook' button (see here for JS and here for PHP), Facebook's OAuth dialog appears, which will prompt the user to log in (if they are not already) or to sign up with Facebook, thereby creating a new account, albeit not under your control.