Database Reference
In-Depth Information
Most interactive web access moved to a different model; you send your
password to the server once in an encrypted session and get a token or
cookie back that you then use to talk to the server. This doesn't provide a
whole lot more security than before—if someone can steal that cookie, he
can impersonate you. That is essentially what a cross-site-scripting (XSS)
attack does. A mitigation that is often used is that the cookie times out after
a period of time, which is why you have to log back in to Gmail every couple
of weeks.
For API access, however, you don't want to re-login. You want to just log
in once and have the API continue to work. Some Google APIs allow a
mechanism similar to cookie-based login, called ClientLogin. BigQuery does
not support ClientLogin because it is not considered secure enough; the
long-lived ClientLogin tokens are too vulnerable.
The other problem with ClientLogin is that you have to send a password to
each site you log in to. This is similar to using the web when you have to
create a new username and password to do everything from bank transfers
to buying movie tickets. Hopefully, you use a different username and
password for the movie site than you do for your bank account, but soon
password management gets difficult. One of the goals of more “advanced”
authorization protocols is that they limit the proliferation of passwords by
limiting the number of places you have to trust to send your password to.
While discussing your authentication wish lists, you also might want to be
able to delegate narrow access to a third party. Maybe you would like to
authorize a third party to print out your photos from Picasa. You trust them
with your photos, but you don't trust them with your Gmail. You also don't
want to send them your Google password. You hear about sites with bad
password management policies all the time, and you'd rather not have your
Gmail account become a vector for a spammer in Nigeria.
Now the requirements are starting to get tricky. You want to reduce the
number of sites you need to trust with your password; you want to give
third parties the ability to perform certain actions on your behalf without
having to trust them completely; you don't want to send a long-lived token
over the wire; and you don't want to send your password unless you have
to. In software engineering, when things start getting complex, people want
to build the “one” solution so that no one else has to implement it again.
Often, this just leads to more complexity. OpenID, for example, attempts
to be a distributed authentication mechanism. It is, however, used more
Search WWH ::




Custom Search