RFC6749 Oauth2.0 四种授权模式


1. 为什么需要Oauth2


   OAuth addresses these issues by introducing an authorization layer
   and separating the role of the client from that of the resource
   owner.  In OAuth, the client requests access to resources controlled
   by the resource owner and hosted by the resource server, and is
   issued a different set of credentials than those of the resource

关键是,OAuth 引入了一个授权层,用来分离两种不同的角色:客户端和资源所有者。从而资源所有者(用户)的credentials,主要是密码,不会暴露给客户端。

2. four roles


resource owner

An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user.
资源拥有者, 如豆瓣用户,假设认证服务器是微信。

resource server

The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.


An application making protected resource requests on behalf of the resource owner and with its authorization. The term "client" does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices).

authorization server

The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.
在认证,授权成功后,发放访问token至客户端, 如微信发放访问token至豆瓣。


3. four grant types

四种获得授权的方式,即client如何拿到access token.

   An authorization grant is a credential representing the resource
   owner's authorization (to access its protected resources) used by the
   client to obtain an access token. This specification defines four
   grant types -- authorization code, implicit, resource owner password
   credentials, and client credentials -- as well as an extensibility
   mechanism for defining additional types.

Authorization Code



The transmission of authorization codes SHOULD be made over a secure
channel, and the client SHOULD require the use of TLS with its
redirection URI if the URI identifies a network resource. Since
authorization codes are transmitted via user-agent redirections, they
could potentially be disclosed through user-agent history and HTTP
referrer headers.

关键在于authorization code只可使用一次,假设resource owner(by user-agent, exp, browser)到client的链接为http,可能被窃听。
因为到authorization server的链接是https, access_token绝不会被暴露,而授权码就算被暴露,也会因用户的重新登录,而让此前中间人获取的access_token失效。

Authorization codes MUST be short lived and single-use. If the
authorization server observes multiple attempts to exchange an
authorization code for an access token, the authorization server
SHOULD attempt to revoke all access tokens already granted based on
the compromised authorization code.

Implicit Grant

相较Authorization Code,authorization server直接返回access token, 关键点在于access token在callback中,以fragment方式返回access token,这样,user-agent访问Web-Hosted Client Resource时,不会带上access token,access token留在本地,注意这种情况下client在本地。

Resource Owner Password Credentials Grant

用户相当信任client,直接给密码client,client用密码获得access token.

Client Credentials Grant

authorization server完全相信client,client通过证书直接拿access token

4. facebook使用的授权模式

在facebook看了facebook, php/android 的sdk.
从php sdk的接口来看,很显然使用了Authorization Code模式,php sdk应该部署在服务器上。
而android sdk,有RFC8252 描述最佳实践。另外注意到,facebook android sdk,在手机端拿到的token,有效期已经长达2个月。RFC-8252-OAuth Implicit Grant Authorization Flow有提到,native apps不推荐使用implicit grant. 这里有待继续深入。

The OAuth 2.0 implicit grant authorization flow (defined in
Section 4.2 of OAuth 2.0 [RFC6749]) generally works with the practice
of performing the authorization request in the browser and receiving
the authorization response via URI-based inter-app communication.
However, as the implicit flow cannot be protected by PKCE [RFC7636]
(which is required in Section 8.1), the use of the Implicit Flow with
native apps is NOT RECOMMENDED.



阅读 1.3k

51 声望
3 粉丝
0 条评论
51 声望
3 粉丝