在一些网站总是看到调用其他网站的信息的实例，比如在人人网中导入MSN联系人，在Facebook中导入gmail，yahoo mail好友，第三方网站不需要总知道你的密码，对于应用的授权完全交给你自己，这种用户账号安全问题的策略使用了Oauth认证。
如下一个的案例： 如果一个用户拥有两项服务：一项服务是图片在线存储服务A，另一个是图片在线打印服务B。如下图所示。由于服务A与服务B是由两家不同的服务提供商提供的，所以用户在这两家服务提供商的网站上各自注册了两个用户，假设这两个用户名各不相同，密码也各不相同。当用户要使用服务B打印存储在服务A上的图片时，用户该如何处理？法一：用户可能先将待打印的图片从服务A上下载下来并上传到服务B上打印，这种方式安全但处理比较繁琐，效率低下；法二：用户将在服务A上注册的用户名与密码提供给服务B，服务B使用用户的帐号再去服务A处下载待打印的图片，这种方式效率是提高了，但是安全性大大降低了，服务B可以使用用户的用户名与密码去服务A上查看甚至篡改用户的资源。
一个典型的OAuth应用通常包括三种角色，分别是：
Service Provider：服务提供者
User：用户
下面是Oauth的认证过程，以及相关的参数：
A. 使用者（第三方软件）向OAUTH服务提供商请求未授权的Request Token。向Request Token URL发起请求，请求需要带上的参数见上图。
然而由于Oauth1.0签名算法太复杂,获取token的方式单一,性能和可伸缩性比较差等缺点，Oauth2.0问世。该机制将认证服务器和资源服务器分开,使用HTTPS安全通道，AccessToken Refresh机制和采用固定的回调。新的标准在认证和授权方面，涉及到四个角色：
Resource Owner: 能够对受保护资源进行访问许可控制的实体。
Resource Server: 能够接受和响应受保护资源请求的服务器。
Protected Resource: 能够使用Oauth请求获取的访问限制性资源。
Client: 获取授权和发送受保护资源请求的应用。
其认证的流程为：
(B) 客户端收到一个访问许可，它代表由资源服务器提供的授权。
(C) 客户端使用它自己的私有证书到授权服务器上验证，并出示访问许可，来请求一个访问令牌。
(D) 授权服务器验证客户端私有证书和访问许可的有效性，如果验证通过则分发一个访问令牌。
(E) 客户端通过出示访问令牌向资源服务器请求受保护资源。
(F) 资源服务器验证访问令牌的有效性，如果验证通过则响应这个资源请求。
User-Agent Flow – 客户端运行于用户代理内（典型如web浏览器）。
Web Server Flow – 客户端是web服务器程序的一部分，通过http request接入，这是OAuth 1.0提供的流程的简化版本。
Device Flow – 适用于客户端在受限设备上执行操作，但是终端用户单独接入另一台电脑或者设备的浏览器
Username and Password Flow – 这个流程的应用场景是，用户信任客户端处理身份凭据，但是仍然不希望客户端储存他们的用户名和密码，这个流程仅在用户高度信任客户端时才适用。
Client Credentials Flow – 客户端适用它的身份凭据去获取access token，这个流程支持2-legged OAuth的场景。
Assertion Flow – 客户端用assertion去换取access token，比如SAML assertion。
可以通过使用以上的多种流程实现Native应用程序对OAuth的支持（程序运行于桌面操作系统或移动折本）。