I'd like to create a piece of code that can be embedded on many different websites (widget).
Is there any way that my code can identify a user without them logging in? I.e, can I use any of the established identity mechanisms floating around the web to reliably identify them across instances of this widget?
I don't need to (nor should I be able to) tap into any information about this user, just identify them.
The websites will be heterogeneous; there's no guarantee that they will have any common aspects, so the widget code needs to be entirely self contained.
What you want to do is what cookies were invented for. But browsers have gotten wise to people being tracked without their permission, and now limit 3rd party cookies.
The Electronic Frontier Foundation recently put up a proof of concept for uniquely identifying a visitor based on attributes of their browser. It's uses things things like:
User-Agent string
http-accept values
timezone
screen resolution and color depth
the installed plugins
if cookies are enabled
It's not guaranteed to be unique, but my browser certainly is, and it will get you on your way to doing the bad things that people don't like.
OpenID is sort of a SSO for the whole internet, yet they still have to sign in to OpenID. Other than that, I can't think of a solution.
I would suggest Open-ID rather than some workaround like this, but if you don't like that solution you might consider something like this:
You can use a cookie from a single domain, then use that domain to redirect to the correct site adding user-id as a parameter or part of the URL-path
For instance a link to add a personal widget on the foo.com -site, could look something like:
http://bar.com/addwidget1?backtoo=http://foo.com/main/
bar.com would own the cookie, change the user preferences and then add user-id to the back-link before re-directing:
foo.com/user-id/
Issues with this approach includes
You need to rewrite every page dynamicly with the user-id.
It's a bit clumsy I think
You can't fully take advantage of web-caches around the net.
The user might loose their cookie.
Benefits
No login
Since you redirect a lot you get stats on the users movement across your sites.
Sounds like you want to implement a Single Sign On framework. Basically when you first see the user, if you don't know them, you redirect them to the single sign on server. Wich authenticates them and redirects them back to you with a authentication token. You verify the authentication token with a web service call to the SSO server. Ff it is valid then you mark that user as signed on.
EDIT
So thinking about it more and reading tovare's answer and your comments. Why not create some javascript code that works like an google ads? You put the javascript on the page and it does an a request to your central tracking server using a dynamic iframe.
Have your tracking server return an image tag with src of the unique id (its own session id) embedded.
<img src=contentserver.com/track.php?id=12345668>
The content server has a server side script (track.php above) that maps its local session id to the unique id received from the tracking server.
The unique id stays the same across all sites.
Edit2
Instead of using an image, use the javascript trick. The content server just requests a javascript file from the tracking server. but the file is a dynamic one generated on the server side. it returns a generated javascript function called unique_id() it returns the unique id from the tracking server. Call the track.php using ajax to determine if this is a unique user.
Use OpenID, or a simplified variant, with your own site as the identity provider. Redirect the user to your identifier site which sets or checks a cookie, then redirect the user back with the user's identity, which was indicated by the cookie, added as a URL argument.
Your identifier site can be an OpenID identity provider which doesn't require any user interaction to authenticate. The sites which receive this identity are probably not OpenID consumers, since they don't offer the user a choice of providers. You can probably do away with some of the signing required by OpenID if your cookie and identifier are signed.
Facebook provides something similar; a site can find the Facebook identity of a user (assuming the user has one) without any action on the user's part.
Related
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.
I have been reading about securing REST APIs and have read about oAuth and JWTs. Both are really great approaches, but from what I have understood, they both work after a user is authenticated or in other words "logged in". That is based on user credentials oAuth and JWTs are generated and once the oAuth token or JWT is obtained the user can perform all actions it is authorized for.
But my question is, what about the login and sign up apis? How does one secure them? If somebody reads my javascript files to see my ajax calls, they can easily find out the end points and the parameters passed, and they could hit it multiple times through some REST Client, more severely they could code a program that hits my sign up api say a thousand times, which would be create a thousand spam users, or they could even brute force the login api. So how does one secures them?
I am writing my API in yii2.
The Yii 2.0 framework has a buil-in filter called yii\filters\RateLimiter that implements a rate limiting algorithm based on the leaky bucket algorithm. It will allow you to limit the maximum number of accepted requests in a certain interval of time. As example you may limit both login and signup endpoints to accept at most 100 API calls within a 10 minutes interval of time. When that limit is exceeded a yii\web\TooManyRequestsHttpException exception (429 status code) will be thrown.
You can read more about it in the Yii2 RESTful API related documentation or within this SO post.
I didn't use it myself so far but from what I did read about it in official docs, and I mean this:
Note that RateLimiter requires
$user
to implement the
yii\filters\RateLimitInterface.
RateLimiter will do nothing if
$user
is not set or does not implement
yii\filters\RateLimitInterface.
I guess it was designed to work with logged in users only maybe by using the user related database table, the default one introduced within the advanced template. I'm not sure about it but I know it needs to store the number of allowed requests and the related timestamp to some persistent storage within the saveAllowance method that you'll need to define in the user class. So I think you will have to track your guest users by IP addresses as #LajosArpad did suggest then maybe redesigning your user class to hold their identities so you can enable it.
A quick google search let me to this extension:yii2-ip-ratelimiter to which you may also have a look.
Your URLs will easily be determined. You should have a black list of IP addresses and when an IP address acts suspiciously, just add it to the black list. You define what suspicious is, but if you are not sure, you can start with the following:
Create something like a database table with this schema:
ip_addresses(ip, is_suspicious, login_attempts, register_attempts)
Where is_suspicious means it is blacklisted. login_attemtps and register_attempts should be json values, showing the history of that ip address trying to log in/register. If the last 20 attempts were unsuccessful and were within a minute, then the ip address should be blacklisted. Blacklisted ip addresses should receive a response that they are blacklisted whatever their request was. So if they deny your services or try to hack things, then you deny your services from them.
Secure passwords using sha1, for example. That algorithm is secure-enough and it is quicker than sha256, for instance, which might be an overkill. If your API involves bank accounts or something extremely important like that, important-enough for the bad guys to use server parks to hack it, then force the users to create very long passwords, including numbers, special characters, big and small letters.
For javascript you should use OAuth 2.0 Implicit Grant flow like Google or Facebook.
Login and Signup use 2 basic web page. Don't forget add captcha for them.
For some special client such as mobile app or webServer:
If you sure that your binary file is secure, You can create a custom login API for it. In this API you must try to verify your client.
A simple solution, you can refer:
use an encryption algorithm such as AES or 3DES to encrypt password
from client use a secret key (only client and server knows about it)
use a hash algorithm such as sha256 to hash (username + client time + an other
secret key). Client will send both client time and hash string to
server. Server will reject request if client time is too different
from server or hash string is not correct.
Eg:
api/login?user=user1&password=AES('password',$secret_key1)&time=1449570208&hash=sha256('user1'+'|'+'1449570208'+'|'+$secret_key2)
Note: In any case, server should use captcha to avoid brute force attack, Do not believe in any other filter
About captcha for REST APIs, we can create captcha base on token.
Eg.
For sign up action: you must call 2 api
/getSignupToken : to get image captcha url and a signup token
respectively.
/signup : to post sign up data (include signup token and
captcha typed by user)
For login action: we can require captcha by count failed logins base on username
Folow my api module here for reference. I manager user authentication by access token. When login, i generate token, then access again, client need send token and server will check.
Yii2 Starter Kit lite
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.
Is it possible to limit the users who can sign in with open id on my site. I have clients that I want to give access to a client area on my website. I don't want anyone with a open id to be able to login just my clients. Is this possible?
One way to do this would be to create a "sign up" form to validate the user. Part of the sign up process would be to associate your OpenID. You can then leave the newly created account in a "pending" mode to be approved by an admin. (note: if you have a different way of adding the clients, you would use that method.)
Basically you would create a profile for a user the same way you would in any other application, except you would replace the UserName / Password portion with OpenID.
OpenID is made for authentification, not for authorization. I am sure, you could make it work (*), however you must keep in mind that OpenID has not been made for this sort of task.
If you want to do it, you must probably restrict the set of allowed OpenID providers to prevent a malicious provider to hand faked/bogus identity URLs to your application (consumer).
(*) how, depends on where you want to enforce the restriction (web server, web framework, etc.)
I'm reading about Federated Login for Google Account Users to figure out how I can have a user log in to a web application using their Google Account.
So towards the end of the process, Google returns a Google supplied identifier which is appended as openid.claimed_id. This means the web application uses this identifier to recognize the user and allow access to application features and data. My question is, is this identifier static? Can I use this identifier to repeatedly id the same user?
Yes. Consider the openid.claimed_id value to be the username. Especially with Google, but this is true for any OpenID Provider that truly implements 'directed identity', don't consider this username to be correlatible with other web sites. Any other relying party besides your own web site will get a different claimed_id value for the same Google user, by design.
Also, be sure to treat this claimed_id as case sensitive.
The specific answer to your question is found in Googles OpenID API documentation:
The Google-supplied identifier, which has no connection to the user's actual Google account name or password, is a persistent value; it remains constant even if the user changes their Google user name and/or email address. This identifier is also a "directed identity", that is, Google returns a different value to each relying party. Google uses the request parameter openid.realm to recognize the relying party, so if the third-party application decides to change this value, all user identifiers will change.
In fact, I just ran into an instance where the google claimed_id had changed for my test user. I was coming to the end of implementing OpenID into my app, and for no apparently reason the claimed_id in the response data is had changed.
I've been testing with this account for the past couple weeks, and the claimed_id was the same this entire time, as expected. Then wham, changed! I looked at the response data many times to verify, and the underlying code to retrieve the data had not changed.
I'm not sure how to handle this at the moment, but I think this is going to throw me for a loop. After initial authentication, users register to the site (as you might expect) and setup a screen name. How are we to verify it is the same user if the claimed_id had changed? We certainly can't use email address, per best practices.
EDIT
Now I have pie in my face! I missed one little detail, that turned out to be a major detail. I change my development environment and was hosting on a different v-host. This effectively change the realm, and this will change the claimed_id response according to the docs.
This was a good lesson for me, as I was about to implement OID on a subdomain in which realm was being set automatically in my code. Now I saved myself a headache down the road, because I would not have been able to use the same user database across all other sub-domains without breaking identity.
updating realm
MORE INFO
Just as a side note - even if you are developing your OpenID solution for one of your subdomains, it might be prudent for you to specify realm to your top-level domain.
e.g., openid.realm = http://*.yourdomain.com
It will allow you to expand your sign-in page across all your subdomains and keep user identity across them.
(optional) Authenticated realm. Identifies the domain that the end
user is being asked to trust. (Example: "http://*.myexamplesite.com")
This value must be consistent with the domain defined in
openid.return_to. If this parameter is not defined, Google will use
the URL referenced in openid.return_to.