I have a .NET Web Api. I want to consume from webs and Mobile Apps, but I don't want the user to sing in or create an acount. Can I make an authentication from IP or domain name or something similar?
I tried to implement a Basic and Oauth Authentication, but don't want to place the plain text with the user and password in javascript webs cause everyone can see it and I can't find a secure way that don't need to ask the user to loggin.
Do you have any ideas?
Edit:
I know that I can use google or facebook account or my own users database... the problem is that i don't want the user to insert their loggin parameters and i am searching a secure alternative to restrict the use of the app.
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 am trying to create a login with facebook using javascript for a chrome extension that will return some data from the server.
I am currently able to login without issues with google and facebook. Google is returning the email address and an unique ID that only applies to my app so I can use that ID to login into my server together with the email address provided.
Facebook returns the real user ID and the email address, meaning that anyone that has access to facebook can find that ID and if they know the email address they will be able to login.
As I do not want to ask the user to login every time that they restart the browser or every few days, what is the best way to get a unique constant secure ID from facebook that is unique to my application?
Naturally if I make it unique in the extension it would not really be beneficial because anyone can read the extension code and then figure out how to get someone else unique ID from their user ID.
The authorization code that Facebook sends is not constant, so I would not be able to send it to the server to authenticate someone.
"Facebook returns the real user ID" - wrong, the api only returns an App Scoped ID. And no one except for the user himself will be able to login. Just use the App Scoped ID, that´s how you identify users in your App. Btw, user IDs are not really something you need to keep secret. Access Tokens are.
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?
I want to check whether a user has any notification of facebook or not.. to do that I thought of curl, but the user have to put his login detail. I wonder is there any better way to do it? The weak point of curl method is that the users will receive warning email because someone loggin from different locality.
Facebook has a security witch prevent you to access the site by cURL.
You better create a facebook application, by using the notification API : https://developers.facebook.com/docs/graph-api/reference/user/notifications
I'm looking for a way to restrict access and password protect an assemble.io website.
The idea is to mimic a web application authorization where there is a login form with user/password fields. In this case there would be just one user and password. The member would login and gai. Access to the restricted area of the application and be able to view/browse beyond the login area.
Being a static website, I want to avoid .htacess basic authentication. Is there a way to do this in assemble? Using pure js or something else which would provide a basic authentication for static websites?
I was imagining sending the user and password to an external API and if there are valid the user is redirected to the restricted area. Don't know how it would deal with the session in this case but maybe there's a js way to deal with them.