SSO和Auth2.0

1. 简介

  • SSO, single sign on, 单点登录。sso多用于多个应用之间的切换，例如百度论坛、百度知道、百度云、百度文库等，在其中一个系统中登录，（登录有效期内）切换到另一个系统的时候，不必再次输入用户名密码。
  • oauth2.0，开放授权，不兼容oauth1.0.允许第三方应用代表用户获得访问权限。可以作为web应用、桌面应用和手机等设备提供专门的认证流程。例如，用qq账号登录豆瓣、美团、大众点评；用支付宝账号登录淘宝、天猫等。
  • sso和oauth2.0在应用场景上的区别在于，SSO是为了解决一个用户在鉴权服务器登陆过一次以后，可以在任何应用（通常是一个厂家的各个系统）中畅通无阻。OAuth2.0解决的是通过令牌（token）而不是密码获取某个系统的操作权限（不同厂家之间的账号共享）。

2. 常规的身份认证流程

1. 登录页，我们提交username和pwd；

2. server进行身份识别认证，认证通过后将用户信息写入session，同时浏览器将身份信息写入cookie；

3. 访问其他页面的时候，浏览器请求会带上cookie，服务端根据cookie找到对应session，相当于完成身份认证。

局限：

  • cookie不能跨域。
  • session是存在于各自应用中的，不能共享。例如：
    • app1.a.com和app2.a.com，主域名一致，不同子域名。这种情况下可以在写cookie时，将域名指定为顶级域名，即a.com。但是注意两个应用的sessionid可是不一致的，两个应用会各自记录自己的sessionid，在登录的时候并不影响，但是退出的时候就会有问题了。如果从app1退出，只会清除session1和cookie，session2还在，意味着app2还是登录状态。这就需要将各个系统的session共享。

3. SSO身份认证流程

1. 用户访问app1，浏览器向app1发出请求。【未登录状态】

2. app1收到请求后，发现浏览器处于未登录状态，返回一个302，跳转访问cas，并附带returnurl【即app1自身地址】。

3. 浏览器收到302后，访问cas。

4. cas返回给浏览器一个登录页。

5. 浏览器展示登录页，用户携带returnurl提交用户名密码到cas。

6. cas进行身份认证，认证成功创建sso的session和认证ticket（ST），返回302，并将ticket一并返回给浏览器

7. 浏览器记录cookie，带着ticket（ST）访问returnurl【app1地址】。（cookie是cas的）

8. app1收到请求后，向cas确认ticket（ST）是否有效。

9. cas验证ticket通过后，返回200给app1。

10. app1记录登录状态并响应浏览器请求（步骤7），返回302（不带ST）。（添加app1的cookie）

11. 浏览器收到302，访问app1地址，此时cookie和session齐全，身份认证完成，向浏览器返回请求的资源。之后（cookie、session有效期内）访问app1，不必再身份验证，直接返回请求资源。【app1登录完成】

12. 用户访问app2，浏览器向app2发出请求。【app2未登录】

13. app2收到请求，发现浏览器处于未登录状态，返回一个302，跳转访问cas，并附带returnurl【即aap2自身地址】。

14. 浏览器收到302，访问cas。（由于步骤7已经记录的cas的cookie，浏览器会在请求时将cookie携带）

15.cas验证身份，由于有cookie存在，直接返回票据ticket（ST2），并让浏览器重定向。

16.浏览器带着ticket（ST2）访问returnurl。

17.app2收到请求后，向cas确认ticket（ST2）是否有效。

18.cas验证ticket通过后，返回200给app2。

19.app2记录登录状态并响应浏览器请求（步骤16），返回302（不带ST）。（添加app2的cookie）

20.浏览器收到302，访问app2地址，此时cookie和session齐全，身份认证完成，向浏览器返回请求的资源。之后（cookie、session有效期内）访问app2，不必再身份验证，直接返回请求资源。【app2登录完成】

4. Auth2.0身份认证流程

oauth2.0定义了四个角色：客户端client，资源所有者resource owner ，资源服务器resource server，授权服务器Authorization server。例如，用qq账号登录美团，美团是客户端，我们用户是资源的所有者，qq的用户信息放在了资源服务器上，对账户授权的工作放在了授权服务器上。

1. 客户端要求用户给与授权。我们打开美团，选择快速登录。
2. 用户同意授权给客户端。我们选择了用qq账号快速登录，同意授权给美团我们的用户信息。
3. 客户端拿到用户给的授权，先授权服务器申请令牌。美团向qq的授权服务器发起申请。
4. 认证服务器对客户端进行认证，确认无误发放令牌。通常手机端会切换到qq端，验证登录状态，提示是否授权，我们确认登录之后，服务器发放令牌。
5. 客户端使用令牌，申请资源。美团向qq申请用户信息。
6. 资源服务器确认令牌无误，同意开放资源。我们用qq的账号登录了美团，美团上显示我们的qq昵称、头像等信息。

oauth2.0定义了四种授权类型：授权码模式authorization code、简化模式 implict、密码模式resource owner password credentials 和 客户端模式 client credentials。授权码模式为功能最为完整，流程最为严密的授权，其他模式为授权码模式的变体或简化。

  • Authorization code grant

    • part 1: The client will redirect the user to the authorization server with the following parameters in the query string:

      • response_type
      • client_id
      • redirect_uri
      • scope: "business" in our app.
      • state: a CSRF token. This parameter is optional but highly recommended. You should store the value of the CSRF token in the user’s session to be validated when they return.

    If authorized, client will get code and state.

    • part 2: The client will now send a POST request to the authorization server with the following parameters:
      • grant_type with the value of authorization_code
      • client_id
      • client_secret
      • redirect_uri
      • code

    If authorized, client will get

    • token_type this will usually be the word “Bearer” (to indicate a bearer token)
    • expires_in
    • access_token
    • refresh_token: can be used to acquire a new access token when the original expires

注意：client_id和client_secret是通过申请的，假如你要请求qq的oauth2.0服务，你得提前申请。如果是你自己的ouath服务，则需要在服务端对请求的client_id和client_secret验证通过。client_id用于初始重定向，client_secret用于应用程序交换令牌的最后一步。

  • Implicit grant:It is intended to be used for user-agent-based clients (e.g. single page web apps) that can’t keep a client secret because all of the application code and storage is easily accessible. The client will redirect the user to the authorization server with the following parameters in the query string:

    • response_type with the value token
    • client_id
    • redirect_uri
    • scope
    • state

    If authorized, client will get

    • token_type this will usually be the word “Bearer” (to indicate a bearer token)
    • expires_in
    • access_token
    • state

  • Resource owner credentials grant：for trusted first party clients (client、resource server是一个公司出品). The client then sends a POST request with following body parameters to the authorization server:

    • grant_type with the value password
    • client_id
    • client_secret
    • scope
    • username
    • password

    If authorized, client will get

    • token_type
    • expires_in
    • access_token
    • refresh_token

  • Client credentials grant: this grant is suitable for machine-to-machine authentication where a specific user’s permission to access data is not required. The client sends a POST request with following body parameters to the authorization server:

    • grant_type with the value client_credentials
    • client_id
    • client_secret
    • scope

  • Refresh token grant

    • grant_type with the value refresh_token
    • refresh_token
    • client_id
    • client_secret
    • scope

    return same as the 2nd time of Authorisation Code Grant

 

posted on 2020-11-02 15:18  joannae  阅读(1276)  评论(0)  编辑  收藏  举报

导航