分类 技术志 下的文章

通过实例理解OAuth2授权

本文永久链接 – https://tonybai.com/2023/12/16/understand-oauth2-by-example

在之前的《通过实例理解Go Web身份认证的几种方式》和《通过实例理解Web应用授权的几种方式》两篇文章中,我们对Web应用身份认证(AuthN)和授权(AuthZ)的几种方式做了介绍并配以实例增强理解。

在现实世界中,还有一大类的认证与授权是在前面的文章中没有作为重点介绍的,那就是OAuth2授权与基于OAuth2之上的OpenID身份认证(OIDC, OpenID Connect)

近期接触到开放平台(Open Platform)的设计和开发,整个开放平台的授权流程都是基于OAuth2打造的,因此在这篇文章中,我就来先来通过实例详细说说OAuth2,OIDC将放在后面的文章中说明。

1. OAuth是什么

OAuth中的O代表了Open,OAuth直译过来就是开放授权OAuth是一个开放标准,允许用户让第三方应用访问该用户在某一网站上存储的私密的资源(如照片,视频,联系人列表等),而无需将用户名和密码提供给第三方应用。

OAuth不是什么新技术了,其原型最早可追溯至2006年末,至今也快小20年了。但直到2010年4月,OAuth 1.0协议才以RFC 5849的形式正式发布。不过OAuth 1.0版本存在两个主要问题,一是当初设计时仅是为了web浏览器应用,随着应用类型的增多,一套授权机制难以应对现实中的所有场景,比如:Web应用场景、移动App应用场景、官方应用场景等,因为这些场景不是完全相同的,这给使用者带去很多负面体验;二是一些安全性的问题(这里就不展开了)。

2012年10月,解决OAuth 1.0上述问题的OAuth 2.0以RFC 6749发布。OAuth 2.0是OAuth协议的下一版本,但不向后兼容OAuth 1.0。OAuth 2.0关注客户端开发者的简易性,同时为Web应用、桌面应用、手机和智能设备定义了专门的授权许可流程,包括:授权码许可机制(Authorization Code)、客户端凭据机制(Client Credentials)、资源拥有者凭据机制(Resource Owner Password Credentials)和隐式许可机制(Implicit)。如今OAuth 1.0已经被废弃,谈到OAuth如无特殊说明,指的都是OAuth2.0版本。

在OAuth2.0的四种授权类型中,最安全的、最广泛使用的也是最常见的就是授权码许可机制(Authorization Code)了。本文后续的说明与示例也都是围绕授权码这种类型的。

2. OAuth2解决了什么问题

仅仅凭借上面关于OAuth的描述,你可能依然无法对OAuth有一个直观和深刻的理解,笔者第一次接触OAuth协议时也是花了不少时间才逐渐“茅塞顿开”,当然本文参考资料中的那些书籍和资料“功不可没”,尤其是OAuth 2.0的RFC协议规范

那么OAuth到底解决的是什么问题?这里我们就用一个非常典型的示例来系统说说一下。

2.1 传统的云盘系统

现在有一个像百度网盘那样的云盘系统(my-yunpan.com),用户可以注册云盘系统的账号,然后将自己的个人数据文件,比如照片、音视频、文档等上传到云盘上保存。

假设这里有一个名为tonybai的用户注册了云盘,并将个人的一些照片文件上传到云盘上做保存和备份:

这是一个我们都可以理解的场景,用户注册云盘账号,然后登录云盘应用后将个人照片上传到云盘,这里使用的身份认证和授权技术方案没有超出《通过实例理解Go Web身份认证的几种方式》和《通过实例理解Web应用授权的几种方式》两篇文章的范畴。

针对这个场景,OAuth定义了三个很容易理解的概念实体:

  • Resource Server:集中存储资源(如用户照片等)的服务,这个示例里就是云盘服务;
  • Resource owner:资源的拥有者,这里就是云盘的用户,比如图中的tonybai;
  • Protected Resource:Resource owner上传并存储在Resource Server中的Resource,受Resource Server保护,这里对应的就是用户上传的照片。

大家先对这三个概念实体有个感性的认识即可,后续备用。

2.2 第三方的照片冲印服务

智能手机时代,数字照片(Digital Photo)将传统的基于胶卷的照片彻底拉下神坛。数字照片是存储在磁盘、手机中或云盘上的,但依然有很多人有将数字照片像传统照片那样冲印出来放在相册里或房间照片墙上欣赏的需求,于是就有了在线照片冲印服务(my-photo-print.com)。

用户注册在线照片冲印服务后,将自己的数字照片上传,交钱冲印即可,冲印好的照片便会经由快递送至用户家中,非常方便。

2.3 Resource Owner要冲印照片

有一天,云盘用户tonybai要挑选一些近期存储在云盘中的照片进行冲印,他搜索到了my-photo-print.com这个第三方的照片冲印服务,但他需要在my-photo-print.com这个应用上重新注册一个账号,再将云盘上的照片下载后重新上传到my-photo-print.com这个服务的空间中才能实现在线冲印。这对于大多数像tonybai这样的用户而言并不是一个很easy的操作,体验上也是糟糕。tonybai在思考:我的照片已经在云盘上了,为什么不可以直接基于云盘上的照片进行冲印呢

2.4 增加开放平台(open.my-yunpan.com)

在tonybai萌生出这个困惑的同时,云盘的产品经理也同步感知到了这个需求,是时候给云盘系统增加开放平台了!这样,第三方应用便可以接入云盘系统,方便快捷地为云盘用户提供各种扩展服务,比如照片冲印、云上视听、数据智能管理等,这也是互联网界熟知的生态建设的套路

下面是照片冲印服务my-photo-print.com注册和接入开放平台的示意图:

照片冲印服务my-photo-print.com注册和接入云盘开放平台后,会得到一个client_id和client_secret,这两个字段是照片冲印服务接入云盘开放平台的凭据,即云盘开放平台对第三方应用进行身份认证的凭据。

不过即使照片冲印服务使用client_id和client_secret这个凭据通过了云盘系统的认证,照片冲印服务依然拿不到云盘系统上用户的照片数据,这里需要一个授权过程,即云盘系统用户(如前文提及的tonybai)告诉云盘系统是否允许照片冲印服务访问自己的数据

那么问题来了!如何实现云盘系统用户对已接入云盘系统的第三方应用的授权呢?下面我们就来探讨一下。

注:这里显然是打了个伏笔,一旦云盘系统建立了开放平台,那么云盘系统的用户对第三方应用的授权流程也就由开放平台规定好了。

2.5 云盘系统用户对第三方应用进行授权的方案

2.5.1 凭据共享方案

一个最简单粗暴的方案就是直接用云盘系统用户的凭据代替用户去云盘系统读取该用户的数据,下面是该方案的示意图:

我们看到:照片打印服务想要获取用户的照片,它首先会提示用户输入其云盘系统上的用户名和密码,然后就会拿着用户的这些凭据合法地进入到该用户在云盘系统中的个人空间并拿到想要的数据。这也意味着用户在云盘系统上可以进行的任何操作,照片打印服务也都有权限进行。此外,一旦用户在多个网站应用上使用的是相同的用户名和密码,那么照片打印服务也可以通过拿到的凭据登录这些网站,并“假扮”用户获得这些网站上的用户数据。这种通过凭据共享来实现第三方应用访问云盘上的用户数据的方案显然是毫无安全底线可言。

2.5.2 专用密码方案

现在你已经看到,共享用户密码并不是一个好方法,那会授予照片打印服务全局的访问权限,它就能代表由它指定的任何用户并访问云盘系统上的所有照片。那是否可以授予照片打印服务一个权限有限的专用密码来实现照片获取呢?此密码仅用于透露给第三方服务,用户自己并不会使用这个密码来登录,只是将它粘贴到所使用的第三方应用里(如下图):

这是一个可行的方案,但这种方案的可用性并不好。它要求用户除了管理自己的主登录密码之外,还要创建(在云盘系统中)、分发(贴到照片打印服务系统中)和管理特殊的凭据。并且,用户管理这些凭据时一般不会区分专用凭据与第三方应用的对应关系,往往是建立一个新专用凭据后,贴到所有第三方应用中使用,这使得撤销某个具体第三方应用的访问权限变得很困难。让用户科学管理这些凭据,本身就给用户带来了心智负担,也可理解为一种不好的体验。

不过,相对于凭据共享方案的不安全,专用密码方案已经是有所进步了,但还远非理想。

2.6 OAuth2授权方案

前面无论是共享凭据还是专用密码方案,都绕开了开放平台,这显然是故意为最终理想方案的出炉做铺垫的 — 没有差方案,如何才能体现出理想方案的好呢!– 是时候叫出超级飞侠了!。

这就是我们提到的OAuth2授权方案。OAuth协议的设计目的是:让用户(Resource owner,比如tonybai)通过OAuth协议将他们在受保护资源(Protected Resource,比如照片)上的部分权限委托给第三方应用(比如照片冲印服务),使第三方应用能代表他们执行操作。这个方案既要考虑提升用户的使用体验,也要考虑提升方案整体的安全性。为实现这些,OAuth在流程中引入了另外一个组件:授权服务器(Authorization Server)。

如果我们将第三方应用(比如照片冲印服务)称为client(客户端应用),加上授权服务器(Authorization Server)以及前面提到的三个概念:Resource Server、Resource owner和Protected Resource,我们就有了5个实体。他们究竟是什么关系呢,又是如何交互的呢?这就是OAuth2.0协议的核心内容。下图是来自OAuth2.0 RFC中的抽象协议流程图,为了好理解,我在图中加入了各个实体对应的示例中的名字:

这是一个抽象图,我们无法从中看出各个流程的细节,但大致可以看出OAuth2授权的关键环节:

  • client(客户端应用,如照片冲印服务)需要用户(Resource owner)的授权,但这个授权过程,用户不会将密码等凭据暴露给client;
  • client凭借授权信息到授权服务器(Authorization server)换取access token;
  • client凭借access token访问用户(Resource owner)在Resource Server(比如云盘系统)上的Resource数据(比如照片)。

接下来,我们来看看细节,我们使用OAuth2中最广泛使用的授权码方案(Authorization code)来展示这个流程,下面是来自OAuth2.0 RFC中的授权码方案流程图:

这个流程图依然很抽象,我们用下面的“分解动作”来解释。

2.6.1 用户(Resource Owner)通过浏览器访问第三方应用(Client,my-photo-print.com)

用户要想使用第三方应用,比如my-photo-print.com服务来冲印自己位于云盘上的照片,他首先要访问到这个第三方应用,如下图所示:

用户通过浏览器(User Agent)打开my-photo-print.com服务的登录页面,这个页面除了提供使用用户名/密码登录之外,还提供了“使用云盘账号”的按钮。该用户不想重新注册一遍my-photo-print.com服务的账号,选择了点击“使用云盘账号”按钮。

2.6.2 用户(Resource Owner)被引导到云盘开放平台登录并对第三方应用进行授权

当用户点击“使用云盘账号”按钮后,对第三方应用进行授权过程便正式开始,下面是一个示意图:

OAuth2.0的授权码模式的第一步便是第三方应用(Client)需要将用户(Resource Owner)引导到云盘开放平台(Authorization Server)的登录页面(/oauth/portal),为用户授权做好准备。在图中第三方应用my-photo-print.com通过网页html内重定向让用户的浏览器(User Agent)重定向到云盘开放平台的授权门户页面,在重定向的请求中,Client带上了自己的一些参数(比如client_id、scope等)。

云盘开放平台(Authorization Server)返回一个用户登录页面,用户(tonybai)输入用户名密码以供Authorization Server做身份认证。注意这个过程完全没有client(照片冲印服务)的参与,用户名和密码不会泄露给第三方。

当用户(如tonybai)点击submit提交凭据信息时,可以向服务端请求,也可以像图中简化版那样直接给出授权范围的提示。弹出的框提示“照片冲印服务需要用户授予两个权限”,如果用户点击“授权”,则会向Authorization Server发起授权请求,连同用户的登录凭据一起,授权请求的路径与参数如下(也可以使用表单提交的方式提交授权请求):

/oauth/authorize?response_type=code&client_id=my-photo-print&state=xyz123&scope=user_info,read_photos&redirect_uri=http%3A%2F%2Fmy-phone-print.com%3A8080%2Foauth%2Fcb

response_type=code表示用户向授权平台请求一个授权码,再强调一下:这个授权码是用户(如tonybai)去申请的,而不是client(第三方应用),后续也是由用户将code告知client(第三方应用)。

cilent_id表示为哪个第三方应用申请的,后续授权平台在发access_token时,可以基于该client_id进行校验。

scope是此次授权的权限列表。

redirect_uri是一个重定向地址,这个地址可以在请求中传递,如果不传递,也可以在client注册开放平台账号时,提供给开放平台(Authorization Server)。

state是一个随机数,OAuth 2.0官方建议使用state以避免CSRF攻击。

2.6.3 用户提供code,client用code换取access_token并读取用户数据

如果Authorization Server通过了用户的请求,便会在应答中带上这次分配给用户的授权码(code),这个授权码是一次性的,一旦使用便会作废,当然Code也会有时效性,一般就是几分钟。

我们继续看下面图示的分解动作吧:

首先,Authorization Server对用户的请求校验通过后,便会分配授权码,并通过下面这个应答返回给用户(浏览器):

HTTP/1.1 302 Found
Location: http://my-phone-print.com:8080/oauth/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz123

用户的浏览器收到这个应答后便会重定向到Location这个地址,这个过程其实是在模拟用户向Client(照片冲印服务)提供code的行为

当Client(照片冲印服务)收到收到用户的code后,它会立即使用这个Code并结合自己的凭据(client_id和client_secert)向Authorization Server申请access_token:

POST /oauth/token HTTP/1.1
Host: open.my-yunpan.com:8081
Authorization: Basic base64(client_id:client_secret)
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=http%3A%2F%2Fmy-phone-print.com%3A8080%2Foauth%2Fcb

这是一个client发向Authorization Server的POST请求,请求参数中,除了固定的grant_type=authorization_code以及code之外,还带了redirect_uri,这个redirect_uri是供Authorization Server校验使用的。此外这个请求是以Client身份申请的,所以在http header中带上了client自己的凭据信息:client_id和client_secert,这里使用的是http basic auth。

Authorization Server对请求验证通过后,便会给出Post应答,access_token等信息都放在应答的包体中:

{
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "token_type":"example",
       "expires_in":3600,
       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
       "example_parameter":"example_value"
}

这里除了包含access_token,还包含了它的过期时间(expires_in)以及一个refresh_token,client可以使用refresh_token在access_token过期前换取一个新的access_token。但从安全角度考虑,client不能无限制的换取新token,所以refresh_token也会被过期时间。一旦refresh_token过期了,那么client就要重新发起一次用户授权过程。

当client收到access_token后,便可以拿着这个access_token到Resource Server(这里是my-yunpan.com)去获取用户(tonybai)的个人资料与照片数据了:

POST /photos HTTP/1.1
Host: my-yunpan.com:8082

method=listall&access_token=2YotnFZFEjr1zCsicMWpAA

my-yunpan.com验证access_token后,便会将tonybai的照片列表返回给client,然后client会返回重定向应答给用户的浏览器。用户浏览器收到重定向应答后,便会向client(照片冲印服务)的/photos端点发起请求,之后便可以在浏览器上看到自己的照片列表了。用户选择要冲印的照片后,创建订单冲印即可。

从用户提交code给client,到用户浏览器显示照片列表,这中间用户可能会有短暂的等待,毕竟client要与Authorization Server和Resource server进行多次交互,用户浏览器也要进行重定向操作。

现在将“分解动作”与OAuth2.0 RFC中的授权码方案流程图结合在一起看,你将会对OAuth有更深刻的理解。

注:OAuth2授权流程原则上是要建立在HTTPS建立的安全通道之上的,这里仅是示例,我们聚焦的是OAuth2流程,所以将使用HTTP进行展示。

3. 示例的具体实现

下面我们用Go语言编写一个可以简单演示OAuth2.0授权流程的示例,该示例与上面描述的OAuth2的“分解动作”基本是可以对应起来的。

示例由三个服务构成:my-photo-print照片冲印服务、my-yunpan云盘服务以及open-my-yunpan云盘开放平台/授权服务,示例对应的目录结构如下:

$tree -L 1 -F oauth2-examples
oauth2-examples
├── my-photo-print/
├── my-yunpan/
└── open-my-yunpan/

在开始编写服务前,我们需要修改一下本机(MacOS或Linux)的/etc/hosts文件:

127.0.0.1 my-photo-print.com
127.0.0.1 my-yunpan.com
127.0.0.1 open.my-yunpan.com

注:由于示例中较少使用到js,且form action的地址也是同源的,并且通过重定向来跳转,所以基本不涉及到跨域问题

注:在演示下面步骤前,请先进入到oauth2-examples的各个目录下,通过go run main.go启动各个服务程序(每个程序一个终端窗口)。

3.1 用户使用my-photo-print.com照片冲印服务

按照流程,用户首先通过浏览器打开照片冲印服务的首页:http://my-photo-print.com:8080,如下图:

这个页面是由homeHandler提供的:

// oauth2-examples/my-photo-print/main.go

// 照片冲印主页,引导用户去授权平台
func homeHandler(w http.ResponseWriter, r *http.Request) {
    fmt.Println("homeHandler:", *r)

    // 渲染首页页面模板
    var state = randString(6)
    mu.Lock()
    stateCache[state] = struct{}{}
    mu.Unlock()
    tmpl := template.Must(template.ParseFiles("home.html"))
    data := map[string]interface{}{
        "State": state,
    }
    tmpl.Execute(w, data)
}

这里我们使用了服务端模板渲染,并将渲染的结果作为应答发给浏览器,home.html模板的内容如下:

// oauth2-examples/my-photo-print/home.html

<!DOCTYPE html>
<html>
<head>
  <title>照片冲印服务</title>
</head>
<body>

  <h3>欢迎使用照片冲印服务!</h3>

  <div>
    用户名: <input name="username"/>
    密码: <input name="password" type="password"/>
    <button>登录</button>
  </div>

  <button id="auth-btn">使用云盘账号登录</button>

  <script>
    var authBtn = document.getElementById('auth-btn');
    authBtn.addEventListener('click', function() {
      var clientId = 'my-photo-print';
      var scope = 'user_info,read_photos';
      var state = '{{.State}}';
      var url = 'http://open.my-yunpan.com:8081/oauth/portal?client_id=' + clientId + '&scope=' + scope+'&state=' + state + '&redirect_uri=http%3A%2F%2Fmy-photo-print.com%3A8080%2Foauth%2Fcb'
      window.location.href = url;
    })
  </script>
</body>
</html>

当用户选择并点击“使用云盘账号登录”时,浏览器将打开云盘开放平台/授权服务的首页(http://open.my-yunpan.com:8081/oauth/portal)。

3.2 使用open.my-yunpan.com进行授权

下面是云盘开放平台/授权服务的首页:

这个页面由open.my-yunpan.com的portalHandler提供:

// oauth2-examples/open-my-yunpan/main.go

func portalHandler(w http.ResponseWriter, r *http.Request) {
    fmt.Println("portalHandler:", *r)

    // 获取请求参数用于渲染应答html页面
    clientID := r.FormValue("client_id")
    scopeTxt := r.FormValue("scope")
    state := r.FormValue("state")
    redirectURI := r.FormValue("redirect_uri")

    // 渲染授权页面模板
    tmpl := template.Must(template.ParseFiles("portal.html"))
    data := map[string]interface{}{
        "AppName":     clientID,
        "Scopes":      strings.Split(scopeTxt, ","),
        "ScopeTxt":    scopeTxt,
        "State":       state,
        "RedirectURI": redirectURI,
    }
    tmpl.Execute(w, data)
}

和照片冲印服务首页一样,这里同样使用了模板渲染的应答页面,对应的portal.html模板的内容如下:

<!DOCTYPE html>
<html>
    <head>
        <title>云盘授权页面</title>
    </head>
    <body>

        <h3>云盘授权页面</h3>

        <p>
            应用{{.AppName}}正在请求获取以下权限:
            <ul>
                {{range .Scopes}}
                <li>{{.}}</li>
                {{end}}
            </ul>
        </p>

        <form id="authorization-form" method="post" action="/oauth/authorize">
            <div>
                用户名:
                <input name="username" id="username" />
                密码:
                <input name="password" id="password" type="password" />
                <input type="hidden" name="response_type" value="code" />
                <input type="hidden" name="client_id" value="{{.AppName}}" />
                <input type="hidden" name="scope" value="{{.ScopeTxt}}" />
                <input type="hidden" name="state" value="{{.State}}" />
                <input type="hidden" name="redirect_uri" value="{{.RedirectURI}}" />
                <button type="submit">授权</button>
            </div>
        </form>

    </body>
</html>

该页面将照片冲印服务要获得的权限以列表形式展示给用户,然后提供了一个表单,用户填写用户名和密码后,点击“授权”,浏览器便会向开放平台授权服务的”/oauth/authorize”发起post请求以获取code,post请求携带了一些form参数,像response_type、client_id、scope、state等。

“/oauth/authorize”端点由authorizeHandler负责处理:

// oauth2-examples/open-my-yunpan/main.go

func authorizeHandler(w http.ResponseWriter, r *http.Request) {
    fmt.Println("authorizeHandler:", *r)

    responsTyp := r.FormValue("response_type")
    if responsTyp != "code" {
        w.WriteHeader(http.StatusBadRequest)
        return
    }

    user := r.FormValue("username")
    password := r.FormValue("password")

    mu.Lock()
    v, ok := validUsers[user]
    if !ok {
        fmt.Println("not found the user:", user)
        mu.Unlock()
        w.WriteHeader(http.StatusNonAuthoritativeInfo)
        return
    }
    mu.Unlock()

    if v != password {
        fmt.Println("invalid password")
        w.WriteHeader(http.StatusNonAuthoritativeInfo)
        return
    }

    clientID := r.FormValue("client_id")
    scopeTxt := r.FormValue("scope")
    state := r.FormValue("state")
    redirectURI := r.FormValue("redirect_uri")

    code := randString(8)
    mu.Lock()
    codeCache[code] = authorizeContext{
        clientID:    clientID,
        scopeTxt:    scopeTxt,
        state:       state,
        redirectURI: redirectURI,
    }
    mu.Unlock()

    unescapeURI, _ := url.QueryUnescape(redirectURI)
    redirectURI = fmt.Sprintf("%s?code=%s&state=%s", unescapeURI, code, state)
    w.Header().Add("Location", redirectURI)
    w.WriteHeader(http.StatusFound)
}

authorizeHandler会对用户进行身份认证,通过后,它会分配code并向浏览器返回重定向的应答,重定向的地址就是照片冲印服务的回调地址:http://my-photo-print.com:8080/cb?code=xxx&state=yyy。

3.3 换取access token并读取用户照片列表

这个重定向相当于用户浏览器向http://my-photo-print.com:8080/cb?code=xxx&state=yyy发起请求,为照片冲印服务提供code,该请求由my-photo-print的oauthCallbackHandler处理:

// oauth2-examples/my-photo-print/main.go

// callback handler,用户拿到code后调用该handler
func oauthCallbackHandler(w http.ResponseWriter, r *http.Request) {
    fmt.Println("oauthCallbackHandler:", *r)

    code := r.FormValue("code")
    state := r.FormValue("state")

    mu.Lock()
    _, ok := stateCache[state]
    if !ok {
        mu.Unlock()
        fmt.Println("not found state:", state)
        w.WriteHeader(http.StatusBadRequest)
        return
    }
    delete(stateCache, state)
    mu.Unlock()

    // fetch access_token with code
    accessToken, err := fetchAccessToken(code)
    if err != nil {
        fmt.Println("fetch access_token error:", err)
        return
    }
    fmt.Println("fetch access_token ok:", accessToken)

    // use access_token to get user's photo list
    user, pl, err := getPhotoList(accessToken)
    if err != nil {
        fmt.Println("get photo list error:", err)
        return
    }
    fmt.Println("get photo list ok:", pl)

    mu.Lock()
    userPhotoList[user] = pl
    mu.Unlock()

    w.Header().Add("Location", "/photos?user="+user)
    w.WriteHeader(http.StatusFound)
}

这个handler中做了很多工作,包括使用code换取access token,使用access token读取用户的照片列表并存储在自己的存储中(这里用内存模拟,生产环境应该使用数据库服务实现),最后返回一个重定向应答。

用户浏览器收到重定向应答后,会重定向访问照片冲印服务的photos端点: http://my-photo-print.com:8080/photos?user=tonybai,以获取该用户的照片列表。photos端点的处理Handler如下:

// oauth2-examples/my-photo-print/main.go

// 待获取到用户照片数据后,让用户浏览器重定向到该页面
func listPhonesHandler(w http.ResponseWriter, r *http.Request) {
    fmt.Println("listPhonesHandler:", *r)

    user := r.FormValue("user")
    mu.Lock()
    pl, ok := userPhotoList[user]
    if !ok {
        mu.Unlock()
        fmt.Println("not found user:", user)
        w.WriteHeader(http.StatusNotFound)
        return
    }
    mu.Unlock()

    // 渲染照片页面模板
    tmpl := template.Must(template.ParseFiles("photolist.html"))
    data := map[string]interface{}{
        "Username":  user,
        "PhotoList": pl,
    }
    tmpl.Execute(w, data)
}

这里使用了photolist.html并结合用户的照片列表数据一起来渲染照片列表页面,并返回给浏览器:

到这里示例演示就结束了,用户通过授权让照片冲印服务读取到了照片数据。

这里还有一个服务没有提及,那就是my-yunpan.com云盘服务,它的实现较为简单,所以这里就不赘述了。

注:生产中,my-yunpan.com云盘服务是要对照片冲印服务的access token进行校验的,这里是演示程序,没有引入数据库或redis来共享access token,因此这里没有校验。

4. 小结

OAuth是一种广泛使用的开放授权机制。它通过引入授权服务器的概念,实现了用户在不共享自己的用户名密码情况下也能安全地向第三方应用提供特定权限的数据访问授权。

本文通过云盘开放平台和第三方照片打印服务的应用场景详细说明了OAuth出现的背景和解决的问题,并结合工作流程图和Go示例代码,通俗易懂地介绍了OAuth2授权码模式的整体交互流程和实现机制。希望大家通过对这篇文章的阅读,能加深对OAuth2工作原理和机制的理解。

文本涉及的源码可以在这里下载。

注:鉴于本人在前端的小白水平,文中涉及的html代码部分在大模型的帮助下完成。渲染出来的页面比较丑陋,还望大家不要责怪:)。

注:Go社区提供了很多OAuth包可以帮助大家快速构建OAuth2的授权服务器,比如:https://github.com/go-oauth2/oauth2等。

5. 参考资料


“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2023年,Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码,关注代码质量并深入理解Go核心技术,并继续加强与星友的互动。欢迎大家加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) - https://gopherdaily.tonybai.com

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • Gopher Daily归档 - https://github.com/bigwhite/gopherdaily

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

简单之道

本文永久链接 – https://tonybai.com/2023/12/11/simplicity

已经退居二线的Go语言之父Rob Pike近日发表了一篇名为“Simplicity”的博文,记述了2009年在Google内部一次圆桌会议上发表的演讲内容。Pike老先生在这个时间点发表这篇文章究竟有何深意呢?是对Go语言演进的路线有所不满吗?我们不得而知。不过,这篇文章的内容却是非常值得我们学习,这里我简单翻译一下,供大家参考。


2009年5月,Google举办了一次内部的“设计巫术(Design Wizardry)”小组讨论会,我有幸与Jeff Dean、Mike Burrows、Paul Haahr、Alfred Spector和Bill Coughran一起发表了演讲。以下是我演讲内容的文字稿(略作了修改)。尽管一些细节可能已经过时,但演讲的主题依然具有重要意义,而且如今它可能比以往任何时候都更为重要

简单胜于复杂

简单的东西更容易理解、搭建、调试和维护,而且最重要的是更易于理解,因为这会带来其他一切好处。让我们来看看google.com的网页,它只有一个搜索框,你输入查询并获取结果,这个简洁的设计是Google成功的一个关键原因。早期的搜索引擎界面要复杂得多,而现在的搜索引擎产品,要么是模仿我们的设计,要么用户体验很差。

那么,Google搜索引擎(GWS)又是如何运作的呢?我瞥了一眼GWS实例的运行参数列表,里面有成千上万的配置标志和数百个参数,还有一些后端机器的名称、后端配置以及一些特性的启用和禁用。其中大多数参数可能是正确的,但我相信也有一些已经过时或错误的。

所以问题是:一个能设计出google.com这样简洁网页的公司,怎么可能同时设计出复杂庞大的GWS搜索引擎呢?答案是,GWS并非从一开始就被“设计”出来,而是通过有机增长逐渐形成的。有机增长的路径非常复杂,每个部分、每次修改看起来都很简单,但综合起来就变得难以维护。

复杂性是乘法效应的。在像Google这样由多个组件组装而成的系统中,如果你让一个组件变得复杂,那么其中的一部分复杂性就会反映到其他组件中。这就是失控的复杂性。

复杂性也是普遍存在的

很多年前,Tom Cargill从贝尔实验室的研究部门休了一年的假,加入了开发部门。他加入的团队每个子系统的代码都被打印出来,装订成册放在员工办公室的书架上。Tom发现其中一个子系统基本上是完全冗余的,大部分功能在其他地方已经重新实现过。于是他花了几个月的时间删除了那个子系统,删掉了1.5万行代码,并从所有人的书架上移走了一整本厚厚的代码目录。这样简化了整个系统,减少了代码量、测试工作量和维护工作量。他的同事们都很高兴。

然而,在评估时出现了问题。Tom得知管理层有一个衡量生产力的指标是代码行数。由于Tom在那一年删掉了那么多代码,他的生产力指标直接变成了负数。更糟糕的是,他的团队的整体生产力也变成了负数。他只能沮丧地回到研究部门。

这个故事给他上了一课:复杂性无处不在。简单性没有获得奖励。

你可以对这个故事嗤之以鼻,但我们与此并不相去甚远。谁会因为删除Google的代码而得到晋升呢?我们沉浸在自己拥有的庞大复杂代码中,新员工需要花费大量的精力去理解,我们也投入了大量的资源来培训和指导他们适应。我们为能够理解和修改这些代码而感到自豪。

Google是一个民主的组织,代码对每个人都是透明的,可以查看、修改、完善和增加功能。但是每增加一点东西,复杂性就会增加。引入一个新的库,复杂性就增加了;再加上一个存储封装,复杂性又增加了;在子系统中添加新选项,配置变得更加复杂。如果对核心基础模块(如网络库)进行这样的修改,整个系统的复杂性都会大大增加。

复杂性就这样逐步累积,其代价以几何级数增长。

另一方面,简单需要付出努力——但大部分工作都在前期。设计简单的系统是非常困难的,但一旦设计完成并实施,后续的维护和操作就会更加容易。选择避免复杂性可以使简化系统的好处成倍增加。

举个例子,来看看我们的查询日志系统。虽然它在完美程度上还有待提高,但在设计初期就被定位为——至今仍然是——Google内部唯一解决特定核心问题的系统。正是由于这个原因,它确保了系统的稳定性、安全性、一致性以及大规模的经济效益。如果每个团队都自行构建日志基础架构,Google绝对不会达到现在的规模。

然而,这种思路并没有被广泛应用,各个团队仍然频繁地提出建立新的数据存储系统、工作流系统、代码库、基础架构等等。

这种重复建设和快速增长的复杂性正在拖累我们,因为复杂系统的运作效率较低。

Google有几条重要的工程原则:代码要可读,要可测试,别惹恼SRE(译注:Site Reliability Engineering,网站可靠性工程),要追求速度。

然而,简单性从未被纳入考虑。但实际上,它比上述任何一条都更为重要。更简单的设计意味着更易于阅读,代码更易于测试,对SRE更易于解释和修复问题。

此外,简单的系统运行速度更快

注意,我强调的是系统设计,而不是代码。有时为了提升性能,确实需要增加代码的复杂性,这可能是无法避免的。然而,复杂的系统从来都不会变得更快,因为调试和交互变得复杂,难以理解。复杂性只会导致低效。

简单性甚至比性能更为重要。复杂性对系统的影响是成倍增加的——增加2%的复杂度只能换来2%的性能提升(或者1%、0.1%等),这完全得不偿失。

等一下,服务器利用率为什么那么低?难道不是因为系统太慢吗?

不是的,利用率低是因为系统过于复杂。我们无法理解系统的性能表现,无论是在单机还是集群环境下。组件之间的交互难以清晰描述。

应用开发人员无法完全理解底层基础架构。

基础架构工程师也无法准确了解网络状况。

很难弄清楚应用程序需要哪些资源,问题层出不穷。

为了弥补这些问题,每个人都在配置中添加各种参数和补丁代码,使得一切变得更加难以调试。

为了确保产品正常运行,我们只能围绕产品建立防护墙,以避免受到外部环境的影响——然而,这只是增加了更多的复杂性。

这是一个死循环

所以请仔细考虑你正在进行的工作,是否可以将其设计得更简单一些?那个功能真的是必需的吗?通过删除、合并或共享资源,是否可以使整个系统变得更简单?请考虑与其他相关团队进行讨论,设计一个更简单、更统一的架构,避免相互之间的制约。

多研究已有系统的适应性,在此基础上进行改进,而不是从头开始构建。如果发现现有系统无法满足需求,也许问题出在你对需求的定义,而不是系统本身。

如果确实需要开发新的组件,请确保它可以被推广和重用,不仅仅为本地团队提供服务。

构建复杂系统很容易。为了赶进度,编码比重新设计更简单、更快。但是技术债务会不断积累,长期来看必然会失败。

我们的代码库比一年前增加了50%。再过一年呢?五年后呢?

如果不能控制复杂性,总有一天不仅仅是利用率低的简单警告。系统会变得过于复杂、运行缓慢,最终导致彻底崩溃。那将是一场“全面崩溃”的灾难。


“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2023年,Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码,关注代码质量并深入理解Go核心技术,并继续加强与星友的互动。欢迎大家加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • Gopher Daily归档 – https://github.com/bigwhite/gopherdaily

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats