oauth认证

⑴ “oauth”的中文意思

oauth本质一种开放的协议，对象是第三方可以使用OAUTH认证服务
简介

OAUTH协议为用户资源的授权提供了一个安全的、开放而又简易的标准。同时，任何第三方都可以使用OAUTH认证服务，任何服务提供商都可以实现自身的OAUTH认证服务，因而OAUTH是开放的。业界提供了OAUTH的多种实现如PHP、JavaScript，Java，Ruby等各种语言开发包，大大节约了程序员的时间，因而OAUTH是简易的。互联网很多服务如Open API，很多大公司如Google，Yahoo，Microsoft等都提供了OAUTH认证服务，这些都足以说明OAUTH标准逐渐成为开放资源授权的标准。
在官方网站的首页，可以看到下面这段简介：
An open protocol to allow secure API authorization in a simple and standard method from desktop and web applications.
大概意思是说OAUTH是一种开放的协议，为桌面程序或者基于BS的web应用提供了一种简单的，标准的方式去访问需要用户授权的API服务。OAUTH类似于Flickr Auth、Google's AuthSub、Yahoo's BBAuth、 Facebook Auth等。

⑵ 手机应用中使用OAuth认证，如何解决信任问题

设置步骤如下：

• 打开设置菜单，找到权限管理选项。

• 打开后你可以看到很多权限。

• 比如读取联回系人的权限。

• 如果答你不想让某个软件读取你的联系人，点开它选择禁止即可。

• 还可以查看某个软件的所有权限，打开设置里的权限管理后，点右侧的应用。

• 点开后软件的所有权限都会显示在其中，如果比较信任某个软件，还可以选择信任选项。

⑶ REST API 只给自己的APP提供接口，需要oauth认证吗

App通常用restful api跟server打交道。Rest是stateless的，也就是app不需要像browser那样用cookie来保存session, 因此用session token来标示自己就够了，session/state由api server的逻辑处理。
如果你的后端不是stateless的rest api, 那么你可能需要在app里保存session. 可以在app里嵌入webkit,用一个隐藏的browser来管理cookie session.
session 和 oauth token 并不矛盾，作为身份认证 token 安全性比session好，因为每个请求都有签名还能防止监听以及重放攻击，而session就必须靠链路层来保障通讯安全了。如上所说，如果你需要实现有状态的会话，仍然可以增加session来在服务器端保存一些状态

⑷ 新浪OAuth和Basic Auth两种方式的区别

开放平台有两种认证方式，一种是Basic Auth，一种是OAuth。
1、Basic Auth（HTTP Auth）
Basic Auth简单点说明就是每次请求API时都提供用户的username和password。
。这种方式优点和缺点都很明显。
优点：
u 使用非常简单，
u 开发和调试工作简单，
u 没有复杂的页面跳转逻辑和交互过程；
u 更利于发起方控制；
缺点：
u 安全性低，每次都需要传递用户名和密码，用户名和密码很大程度上存在被监听盗取的可能；
u 同时应用本地还需要保存用户名和密码，在应用本身的安全性来说，也存在很大问题；
u 开放平台服务商出于自身安全性的考虑（第三方可以得到该服务商用户的账号密码，对于服务商来说是一种安全隐患），未来也会限制此认证方式（Twitter就计划在6月份停止Basic Auth的支持）
u 用户如果更改了用户名和密码，还需要重新进行密码校验的过程。
2、OAuth
OAuth为用户资源的授权提供了一个安全、开放的标准，将会是以后开发平台普遍遵守的，目前Twitter、Sina微博、豆瓣、Google等都提供对它的支持。它分为几个交互过程：
1）应用用APP KEY和APP SECRET换取OAuth_token；
2）应用将用户引导到服务商的页面对该OAuth_token进行授权（可能需要输入用户名和密码）；
3）服务商的页面跳转回应用，应用再根据参数去服务商获得Access Token；
4）使用这个Access Token就可以访问API了。
上述过程如下图所示：
OAuth认证过程
OAuth的优点：
u 安全性高，用户的账户和密码只需要提供一次，而且是在服务商的页面上提供，防止了Basic Auth反复传输密码带来的安全隐患；
u Access Token访问权限仅限于应用，被窃取不会影响用户在该服务商的其他服务；
u Access Token即使被监听丢失了随时可以撤销，不像密码丢失可能就被别人篡改了；
u 用户修改了密码也不会影响该应用的正常使用。
OAuth和Basic Auth两种方式的区别, OAuth是一种比较通用的，安全的认证方式，不需要用户名密码，只需要用户授权；basic auth是一种基于用户名密码的认证，每次访问都需带上用户的用户名密码。

⑸ oauth认证服务端怎么生成app key和app secret

oauth认证服务端的提供商会提供相应的界面让你注册，注册后就会分配给你key和secret。
比如 网络云平台，腾讯云平台，新浪开发者平台 之类的。

⑹ OAUTH，OPENID，SAML，CAS做统一认证与授权时有什么区别

OpenID是Authentication
OAuth是Authorization

前者是网站对用户进行认证，让网站知道逗你是你所声称的URL的属主地
后者其实并不包括认证，只不过逗只有认证成功的人才能进行授权地，结果类似于逗认证+授权地了。OAuth相当于：A网站给B网站一个令牌，然后告诉B网站说根据这个令牌你可以获取到某用户在A网站上允许你访问的所有信息

如果A网站需要用B网站的用户系统进行登录（学名好像叫federated login），它可以

选择OpenID认证，然后通过attribute exchange获取用户的昵称或其他通过OpenID暴露出来的用户属性，或者
选择OAuth认证，获取到token后再用token获取用户昵称或其他允许被访问的信息

⑺ OpenID 和 OAuth 有什么区别

OpenID是Authentication
OAuth是Authorization

前者是网站来对用户进行认自证，让网站知道“你是你所声称的URL的属主”
后者其实并不包括认证，只不过“只有认证成功的人才能进行授权”，结果类似于“认证+授权”了。OAuth相当于：A网站给B网站一个令牌，然后告诉B网站说根据这个令牌你可以获取到某用户在A网站上允许你访问的所有信息

如果A网站需要用B网站的用户系统进行登录（学名好像叫federated login），它可以

选择OpenID认证，然后通过attribute exchange获取用户的昵称或其他通过OpenID暴露出来的用户属性，或者
选择OAuth认证，获取到token后再用token获取用户昵称或其他允许被访问的信息

⑻ oauth2.0怎么实现单点登录

要实现SSO，需要实现以下主要的功能：所有的应用系统共享一个身份认证系统。统一的身份认证系统是SSO的前提，认证系统的主要功能是将用户的登录信息和用户信息库相比较，对用户进行登录认证。认证成功后，认证系统应该生成统一的认证标志（ticket），返还给用户。另外，认证系统还应该对ticket进行效验，判断其有效性。所有应用系统能够识别和提取ticket信息要实现SSO的功能，让用户只登录一次，就必须让应用系统能够识别已经登录过的用户。应用系统应该能对ticket进行识别和提取，通过与认证系统的通讯，能自动判断当前用户是否登录过，从而完成单点登录的功能。以上内容都来自网络。 如何使用CAS实现单点登录一、简介CAS（Central Authentication Server中央验证系统）是耶鲁大学研发的单点登录系统。系统为了安装考虑默认是需要证书验证的。本人使用的环境为：apache-tomcat-6.0.30(原来用的是tomcat7，但中途遇到了8443端口无法验证的问题，怀疑是版本的原因，因此换成了tomcat6。PS：最后找出了原因是域名的问题，后面将会提到)。

⑼ 新浪微博OAuth2.0 认证怎么实现自动登录

根据Twitter的API Wiki，基本的OAuth验证workflow如下：
1. 程序利用 http://api.twitter.com/oauth/request_token来从twitter.com那里获取一个request token。
2. 然后程序引导用户到 http://api.twitter.com/oauth/authorize页面。
3. 用户如果同意授权，twitter.com则会显示一个7位数字的PIN码。
4. 用户需要将PIN码复制，然后回到程序那里。
5. 之后程序要提示用户输入得到的PIN码。
6. 然后程序将PIN码作为参数oauth_verifier的值,接着调用 http://api.twitter.com/oauth/access_token去核实PIN码，从而将request_token 换成access_token。
7. Twitter之后会返回一个access_token，程序就此token来生成之后的OAuth签名。

⑽ OAuth2.0的认证授权过程

在认证和授权的过程中涉及的三方包括：
1、服务提供方，用户使用服务提供方来存储受保护的资源，如照片，视频，联系人列表。
2、用户，存放在服务提供方的受保护的资源的拥有者。
3、客户端，要访问服务提供方资源的第三方应用，通常是网站，如提供照片打印服务的网站。在认证过程之前，客户端要向服务提供者申请客户端标识。
使用OAuth进行认证和授权的过程如下所示:
用户想操作存放在服务提供方的资源。
用户登录客户端向服务提供方请求一个临时令牌。
服务提供方验证客户端的身份后，授予一个临时令牌。
客户端获得临时令牌后，将用户引导至服务提供方的授权页面请求用户授权。在这个过程中将临时令牌和客户端的回调连接发送给服务提供方。
用户在服务提供方的网页上输入用户名和密码，然后授权该客户端访问所请求的资源。
授权成功后，服务提供方引导用户返回客户端的网页。
客户端根据临时令牌从服务提供方那里获取访问令牌。
服务提供方根据临时令牌和用户的授权情况授予客户端访问令牌。
客户端使用获取的访问令牌访问存放在服务提供方上的受保护的资源。 OAuth 1.0在2007年的12月底发布并迅速成为工业标准。
2008年6月，发布了OAuth 1.0 Revision A，这是个稍作修改的修订版本，主要修正一个安全方面的漏洞。
2010年四月，OAuth 1.0的终于在IETF发布了，协议编号RFC 5849。
OAuth 2.0的草案是在2011年5月初在IETF发布的。
OAuth is a security protocol that enables users to grant third-party access to their web resources without sharing their passwords.
OAuth是个安全相关的协议，作用在于，使用户授权第三方的应用程序访问用户的web资源，并且不需要向第三方应用程序透露自己的密码。
OAuth 2.0是个全新的协议，并且不对之前的版本做向后兼容，然而，OAuth 2.0保留了与之前版本OAuth相同的整体架构。
这个草案是围绕着 OAuth2.0的需求和目标，历经了长达一年的讨论，讨论的参与者来自业界的各个知名公司，包括Yahoo!, Facebook, Salesforce, Microsoft, Twitter, Deutsche Telekom, Intuit, Mozilla, and Google。
OAuth 2.0的新特性： 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的支持（程序运行于桌面操作系统或移动设备）
application support (applications running on a desktop or mobile device) can be implemented using many of the flows above.
持信人token
OAuth 2.0 提供一种无需加密的认证方式，此方式是基于现存的cookie验证架构，token本身将自己作为secret，通过HTTPS发送，从而替换了通过 HMAC和token secret加密并发送的方式，这将允许使用cURL发起APIcall和其他简单的脚本工具而不需遵循原先的request方式并进行签名。
签名简化：
对于签名的支持，签名机制大大简化，不需要特殊的解析处理，编码，和对参数进行排序。使用一个secret替代原先的两个secret。
短期token和长效的身份凭据
原先的OAuth，会发行一个 有效期非常长的token(典型的是一年有效期或者无有效期限制)，在OAuth 2.0中，server将发行一个短有效期的access token和长生命期的refresh token。这将允许客户端无需用户再次操作而获取一个新的access token，并且也限制了access token的有效期。
角色分开
OAuth 2.0将分为两个角色：
Authorization server负责获取用户的授权并且发布token。
Resource负责处理API calls。