Thanks for weighing in. Much appreciated. Here are my thoughts.
I see two separate issues here: User Authentication vs. Application
User Authentication: Ensuring that the Twitter user is who they say
Application Authentication: Ensuring that the Application is who it
says it is (i.e. the tweet is really coming from "TweetDeck" and not
some other application pretending to be TweetDeck).
I understand that Basic Auth, as is, is not a secure solution.
Transmitting unencrypted credentials in the clear is never a great
idea. What about combining Basic Auth with a form of public/private
key encryption? Using PGP as an example, Twitter could publish it's
public PGP key. Applications using Basic Auth would have to encrypt
the username and password with that key and submit the encrypted
username and password as the Basic Auth credentials. Twitter decrypts
them server side and processes authentication normally. Developers
wouldn't have to include any sensitive information in their source
code, and the credentials would always be transmitted in an encrypted
fashion. PGP is a fairly robust standard, with lots of free resources
available to the development community across many languages.
This is a thornier issue that I'm not sure how to solve without having
to bundle some sort of sensitive information in the source code of an
application. However, I think the issue becomes more manageable if
User Authentication is separated from Application Authentication.
I have no doubt that many of the folks on this list have good ideas on
how to solve the second problem.
On Jul 1, 12:46 pm, Matt Sanford <m...@twitter.com> wrote:
> Please, take your time and write a well thought out reply. One-
> line snarky comments, while fun to write and sometimes to read, steal
> time from everyone reading the list, including all of the Twitter API
> engineers. They also make the list look less inviting to new comers.