我们有一个App，可以通过用户名密码登录我们的服务器。
现在我们有一个需求，就是从app里面打开网站的一个链接。这个链接是需要登录才能打开的。由于我们的app已经登录了服务器，因此我们想从app里面打开这个链接时，不再让用户又登录一次。
我们参考了OAuth机制做了下面的方案，但是不知道：
- 是否够安全？
- 把认证和授权分开来是否过度设计？
- 这个方案如果用在客户端上，也就是说客户端获得access token以后，就可以凭access token访问服务器资源，是否够全安？
请大神指教！
说明：
(1) 使用HTTPS保护明文传送的密码或者密码的哈希码；
(2) Request Token存活时间很短；
(4) Access Token存活时间由各个业务系统定
补充一个典型流程的详细描述：
我把流程描述得细一点。
(1) 客户端App使用HTTPS GET，链接“认证服务器”，提交用户ID和密码（明文）；
(2) 认证服务器验证用户ID和密码正确，生成一个32位的随机字符串作为Request Token，返回给客户端App，并在认证服务器中把Request Token关联到用户ID；
(3) 客户端使用HTTP GET链接到“授权服务器”，提交Request Token；
(4) (5) (6) 授权服务器拿Request Token到“认证服务器”查询，如果查到了userId，则生成一个Access Token，对应到UserId，并返回给客户端App，同时要求“认证服务器”销毁Request Token；如果Request Token超过5分钟没有被使用，会自动被删除；
(7) (8) 客户端App打开手机App浏览器，用浏览器向网站发起一个HTTP GET 请求，用Access Token做参数；
(9) (10) (11) 网站拿Access Token到授权服务器查找对应的UserId，如果找到了，则把浏览器请求的数据返回给浏览器；
2015.4.3更新：
我在知乎上看到 知友 @secloud 在这里 帮你深入理解OAuth2.0协议 提到一个 IAM 服务，说是比较适合客户端使用HTTP RESTful API去访问服务器资源的情况，可是我找了好久没有找到怎么实现IAM的资料。
倒是找到这篇：5 Keys To Web App Token Authentication ，讲怎么使用Token来做Web和App通用的用户身份认证。文中提到不能什么都往OAuth上靠，OAuth的应用场景，是第三方认证。如果云和端都是自有系统，就做简单的Token验证好了。我觉得这个结论挺靠谱的。
2015.4.3第二次更新
查了一些资料，觉得上面的结构不对。
1. OAuth 2.0 - Authorization Code Grant和Implict Grant类型适用于第三方认证，不符合我们的应用场景，即我们的客户端是自有的、可信的。应该适用OAuth 2.0 - Client Credentials Grant模型
2. 客户端使用Request Token去换取Access Token的过程多余，不会增加任何安全性，反而增加复杂度；
因此，所谓的“授权服务器”可以去掉。
其实，JSON Web Token (JWT) 是专门为兼容Web和Mobile App身份认证设计的，目前正在进入OAuth 2.0草案，和OAuth 2.0 - Client Credentials Grant模型相比，JWT通过对token进行加密或者签名，还规定了用户身份信息的数据结构。未来如果我们有更高的安全性和性能方面的需要，再考虑。
参考：
http://tools.ietf.org/html/rfc6749
https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32
https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookie...
https://auth0.com/blog/2014/01/27/ten-things-you-should-know-about-tok...
http://alexbilbie.com/2013/02/a-guide-to-oauth-2-grants/
挺好的，Request Token是长时间保存的，Access Token是一次性的是吧？
个人认为授权服务器是多余的，client游览需要登录的页面，直接把token通过cookie，传给网站后台服务器，网站后台服务器拿到token去认证服务器验证，验证成功就返回页面内容，验证失败就返回未登录。