With OAuth 2.0, it is pretty straight forward for a developer to authenticate a user via another service in order to obtain its data, e.g. get tweets from a Twitter user or fitness data via RunKeeper, without getting to know the users credentials.

What was used before OAuth 1.0 and what other technologies are being used? Were credentials often exposed to the developer/service before OAuth?


"Back in the day" we didn't really have any standards prior to oauth, everything was hand rolled and custom. (so for example the photobucket API provided its own direct authentication mechanism. ) Usually token based authentication with a API key (or even plain credentials. )

Back then the majority of online services were 'islands' of their own and didnt really provide much in the terms of data exchange or single-sign-on.

In more 'serious' situations (e.g. credit card transactions. ) it was often a combination of white-listed IP, authentication token, and a custom POST-BACK URL.

The web was a very very very different place 20 years ago compared to how it is today.


There are several techniques that are still being used beside OAuth.

  • API keys/Service keys
  • Whitelisting IP's
  • User/Password Login
  • Token Login (non OAuth)... eg. custom implementation.
  • none, just a 'secret' web-endpoint.

and often a combination of them.

What you saw often was a combination of whitelisting and one of the other techniques.

OAuth was designed to limit the rampant "leaking" of user login credentials, by implementing a system of token and authentication (not based on user information)

it is even designed with thoughts of replacing the tradional Username/password system. (in conjunction with openid which does a similar thing though other mechanisms, that work amazingly in unison).

  • I edited the question to reflect some of your input. Do you know of any "package" or standards that describe what you mentioned above? Thanks! – Simon Cedergren Malmqvist Mar 18 '15 at 10:42

Remember in web 0.99, the idea was to maintain a certain amount of control over access to resources. So you, as the middleware developer, would get a user+password combination that would uniquely identify your requests over many different transport schemes ( the internet is not just www ). The idea extended to not just the act of logging in, the data itself had a schema that might not have been so readable up until you forked over money for access. xml and the transform style sheets were the end result -- they're the tag based equivalent of ASN.1 and BER.

Now, the long running goal of single sign on services have permeated the entire ecosystem, and together with the spread of usable/human readable information sharing ( json! ), resulted in the openid/oauth combination as a means of being able to handle audit purposes on information use and access.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.