All I want is a persistent membership system and easy registration/login process for my several social applications.
I don't really need their e-mail addresses or personal information.
However, I don't want to convert my websites into an anonymous board or spamming area for bots, etc. and I don't want to force my visitors to login through their Facebook or Google accounts.
What do you recommend in this case?
Thanks.
You can't have it both ways. Either you want an anonymous site or you need some type of authentication/identification.
There are several easy options for authentication.
E-mail only. You can do authentication with e-mail only and cookies, no password. This isn't common and is often used in addition to passwords for high-security scenarios, but can be used without passwords for even simpler security. Basically have users log-in with their e-mail only. Then send them a confirmation mail and they click a link in the confirmation mail. When they click the link, store a permanent cookie and from then on they're authenticated. If they loose the cookie, they can repeat the process and authenticate again with the same e-mail address. No manual account creation, no passwords. It's really just as or even more secure than using a password. It's a little cumbersome though to get an e-mail to login, but hopefully cookies will not be lost. Several of my banking/credit card companies do this in addition to e-mail and the only time I notice is when I change computers.
E-mail/password. Don't downplay the usefulness and simplicity of a email/password authentication. Users are accustomed to id and it works fine. As long as you have it isolated to a single small form to create an account, it won't really get in the way.
OpenID. I believe all public website should support OpenID as an available authentication mechanism. For people and sites that use it, it's wonderful. Simple authentication and easy to use. Setup is painful for people that don't know what it is or how to use it, so I wouldn't recommend using OpenID only except for techie sites, but it's a great alternative.
I'd suggest you to use OpenID authentication on your website. This way, you need not to worry about the hassles of storing and retreiving user data on your server plus offer the facility to user to use thier OpenID login credentials for your website.
Kimd regards,
Dorcy
Related
I've recognized with Oauth2 that users are continuously being confused because they sign up with Facebook, then when they return to the site and forget which social media platform they clicked, they make a new account and believe their old account was deleted!
I realize there are some preventatives that can be taken, but that's not always the case. Would it be better to only offer email/password to avoid these issues, especially for websites where the user's data is critical (games, courses, etc).
There is no magic wand for the users who has forgotten what oauth provider the user has used for the site to register. This is especially a problem when the site offers multiple oauth ways. There are few ways to reduce the duplicacy.
Auto sign-in if the user is already signed in to the provider. Most oauth provider support this via auth cookies.
Have an extra logic written inside your site to merge accounts or recognize mail address. Most users use the same mail id for facebook, google or msa.
I'm trying to create a website to authenticate users through the use of a throwaway password where the assumption is that the user might not use the website again (basically a one time access).
I have done my research on OTP and various solutions to authentication but these don't seem to fit my requirements, most of them seem to rely on users having login credentials to the website whereas my system would allow them access without the need for registering.
The implementation of passwordless authentication by Auth0 seems to fit what you're describing. Even if you were not considering a third-party provider it may be useful to go through the documentation.
Basically, a user can login to a site without any need for a sign-up process. They can do so just by requesting that a one time code is delivered to them, for example, either by email or SMS.
This way, they can get quick access without having to setup a user and in the event that they do come back your application can recognize this because they will most likely be using the same mechanism, that is, you can use the email or mobile phone as the unique identifier.
Disclosure: I'm an Auth0 engineer.
If you do not require your users to register, why do you need authentication at all?
Why not just set a cookie with an unique identifier on the first visit? You can store data at the server side associated with that identifier. Keep track of when you last saw the user, and if they do not return within a certain period, you can delete any data you stored for that user.
Currently I have a lot of sites those requires login. All logins different with each other. Different user name, different password for each person. Now I'm looking for some improvement, like gmail and youtube. You know after logged in www.google.com, other sites like youtube, mail.google.com etc, they login automatically. How they did it?
There are a few different ways of doing this:
Use OpenID. This allows users to use the same username and password as they do on other sites (such as SO). There are multiple providers for this.
Use Facebook's Auth API.
Both of the methods above remove the need to implement your own form of authentication.
However, if you want to maintain your own user list from a central location, see this thread for information on how to implement this type of system.
Which are the steps must I follow to implement a token authentication in my web page?
Any summary or links will be appreciated.
I want to implement similar to Facebook or Google, first time client loggin and receive token and then use it in next actions.
I read also about OAuth but I don't want to give access to my application from 3rd party.
Thanks for the long response and it seems clear to me I need to read more about this.
What I want is to know the "steps" to implement a basic web application that uses token authentication. That is user logging once and then can make some actions: add content, edit, etc.
I know what I'm saying is similar to a session, where server adds a SESSION_ID on the HTML header and later request are identified and associated with that session. I read sessions way isn't good to scale so I want to implement a similar system like gmail or facebook before they go to OAuth. Probably I'm talking about something similar to oauth (i don't read in much depth) but witj two-legged instead three-legged.
You should think about your requirements, pick an appropriate protocol and some decent piece of software that implements it.
It's really hard to say more without more details:
are you talking about authentication for one or for multiple web applications? do you need single sign on between different web applications?
should all user data be stored on your server or should user be able to login e.g. with the google account?
should the token contain informations about the user?
on what platform are your applications developed?
what authentication method should be used?
do you want to realize a portal?
There is a really wide range of protocols and tools which might or might not fit to your requirements:
http://en.wikipedia.org/wiki/Category:Authentication_methods
http://en.wikipedia.org/wiki/Category:Identity_management_systems
I personally like CAS ( http://www.jasig.org/cas) for token-base SSO between multiple web applications. It's Java based but also has some support for PHP and .Net.
OpenID is fine, if you want to allow users to login with their Google, Yahoo, whatever account (configurable...) and don't want to store user information by yourself.
Kerberos/SPNEGO is the way to go if you want to haven integrated windows-sso for your corporate intranet applications.
For university applications SAML/Shibboleth probably is best. Outside universities it's somewhat less popular, probably cause it's a fairly complex protocol.
Oh and I almost forget: Most of the web frameworks/standards have there own version of plain-old "form based authentication". Where a user goes to a login form enters its username and password. Both are with or without SSL transported to the web/application server. The server validates it against some kind of database and gives a cookie to the user, which is transmitted and validated every time the user sends a request. But beside all this shiny protocols this seems to be pretty boring :-)
And before doing anything with web authentication, you might think for a moment about web security in general ( http://journal.paul.querna.org/articles/2010/04/11/internet-security-is-a-failure/ http://www.eff.org/files/DefconSSLiverse.pdf) and what you can do to not make it even worse on your site ( http://www.codinghorror.com/blog/2008/08/protecting-your-cookies-httponly.html http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010.pdf).
see your point.
On the protocol level a very simplistic token approach is HTTP Basic Authentication. But this often doesn't fit, as there is no logout function etc.
A custom, simple cookie based approach can for example look like this:
The server generates some kind of secret (a value that is hard to guess)
When a user tries to access a protected resource, he is redirected to a login form
after successful authentication he gets a cookie. This cookie contains three values: username, timestamp and a hash of {username server-secret timestamp}.
with every user request the server recalculates the hash values and compares it to the value which the client sends in its cookie
(needs more consideration of: httponly and secure flag, transport layer security, replay attacks etc)
Amazon S3 stores its authentication token in an HTTP Header and uses HMAC for calculating it. It's described here: http://docs.amazonwebservices.com/AmazonS3/latest/dev/index.html?S3_Authentication.html (Not necessarily recommended for using with a browser based web application)
If there is a book about REST anywhere near you, you may look if it has a chapter about authentication. Probably things are much nicer explained there than here :-)
There are some frameworks which are capable of doing this kind of authentication. For security reasons it would make sense to check them first before implementing your own stuff.
I'd like to be able to give my users the ability to display their recent tweets on their profile on my website.
I have a PHP twitter wrapper and understand how to make API calls etc, but I'm just wondering how to manage the user information.
What is the best practice here? I want them to be able to enter their credentials once, but I would imagine storing everyones username/password myself isn't the best way to go about it.
Is there a way to make an authenticated call once, and have twitter remember it?
Should I store the usernames/passwords and then just make a call when displaying the tweets?
Any advice here would be great.
Thank you,
Use OAuth, no need to ask users for their passwords:
http://apiwiki.twitter.com/Authentication
I think everyone would/should probably agree that storing the twitter usernames/passwords is bad, I can't believe they ever created a situation where you needed it.
You should never store unencrypted credentials of any kind. If your solution involves holding onto a plaintext password, even for a brief time, you need to rework something.
Absolute best practice would be to hold no information yourself - use cookies or OAuth to handle your authentication. A session token or cookie can be disabled by the user at will, giving them control over the behavior of your site.
Next best thing (although still pretty undesirable) would be to hold non-reversibly encrypted credentials to resend to Twitter whenever you need to display tweets.
You don't need their passwords to pull their latest tweets, unless their profiles are locked, simply pull the feed from http://twitter.com/statuses/user_timeline/username.rss
You should look at Twitter's OAUTH support (although they have disabled it). This enables you to prompt the users once, and then store a response from twitter which will allow you to post
Tweets that you would want up on your web site are generally public anyway.
If you did need to authenticate somewhere (perhaps allow users to send new tweets) on a user's behalf, the best practice is to prompt the user at the time you initially authenticate and then store whatever authentication token is returned by the resource rather than the credentials used to get it.