OAuth是一个在不提供用户名和密码的情况下，授权第三方应用访问Web资源的安全协议。
常用的应用 OAuth 的场景，一般是某个网站想要获取一个用户在第三方网站中的某些资源和服务。比如在人人网上，想要导入用户MSN里的好友，在没有OAuth时，可能需要用户向人人网提供MSN用户名和密码。这种做法使得人人网会持有用户的MSN账户和密码，虽然人人网承诺持有密码后的安全，但这其实扩大了攻击面，用户也难以无条件地信任人人网。
而OAuth 则解决了这个信任的问题，它使得用户在不需要向人人网提供MSN用户名和密码的情况下，可以授权MSN将用户的好友名单提供给人人网。
在OAuth 1.0中，涉及三个角色，分别是：
在新版本的OAuth中，又被称为Client、Server、Resource Owner。在上面的例子中，Client是人人网，Server是MSN，Resource Owner是用户。
我们再来看一个实际的场景。假设 Jane 在 faji.com上有两张照片，他想将这两张照片分享到 beppa.com，通过OAuth，这个过程是如何实现的呢？
Jane 在 beppa.com 上，选择要从 faji.com 上分享照片。
在 beppa.com 后台，则会创建一个临时凭证（Temporary Credentials), 稍后 Jane 将持此临时凭证前往 faji.com。
然后页面跳转到 faji.com 的 OAuth 页面，并要求 Jane 登录。注意这是在faji.com 上登录！
登录成功后，faji.com 会询问 Jane 是否授权 beppa.com 访问 Jane 在faji.com 里的私有照片。
如果Jane 授权成功，faji.com 会将Jane带来的临时凭证（Temporary Credentials）标记为 ”Jane 已授权“，同时跳转回 beppa.com, 并带上临时凭证（Temporary Credentials）。凭此，beppa.com 知道他可以去获取Jane的私有照片了。
对于 beppa.com 来说，它首先通过Request Token 去 faji.com 换取 Access Token，然后就可以用Access Token 访问资源了。Request Token 只能用于获取用户的授权，Access Token才能用于访问用户的资源。
最终，Jane 成功地将他的照片从 faji.com 分享到 beppa.com上。
我们也可以参考如下新浪微博开放平台的OAuth 的授权过程，它与上面描述的过程是一样的。
常用的需要用到OAuth 的地方有桌面应用、手机设备、Web应用，但OAuth 1.0 只提供了统一的接口。这个接口对于Web应用来说尚可使用，但手机设备和桌面应用用起来则会有些别扭。同时OAuth 1.0 的应用架构在扩展性方面也存在一些问题，当用户请求数庞大时，可能会遇到一些性能瓶颈。为了改变这些问题，OAuth 2.0 应用而生。