Go 1.22新特性前瞻

本文永久链接 – https://tonybai.com/2023/12/25/go-1-22-foresight

美国时间2023年12月20日,Go官方宣布Go 1.22rc1发布,开启了为期2个多月的、常规的公测之旅,Go 1.22预计将于2024.2月份正式发布!

除了在官网下载Go 1.22rc1版本进行新特性体验之外,我们还可以通过在线的Go Playground选择“Go dev branch”来体验(相比下载安装,在线版本体验会有一些局限):

注:关于Go的多种安装方法,《Go语言第一课》专栏有系统全面的讲解,欢迎订阅阅读。

本文将和大家一起看看Go 1.22都会带来哪些新特性。不过由于目前为时尚早,下面列出的有些变化最终不一定能进入到Go 1.22的最终版本中,所以切记一切变更点要以最终Go 1.22版本发布时为准。

1. 语言变化

Go 1.22的语言特性变化主要是围绕for loop的

1.1 loopvar试验特性转正

Go 1.21版本中,作为试验特性loopvar在Go 1.22中正式转正。如果你还不知道这个特性是啥,我们来看一下下面这个最能说明问题的示例:

// go1.22-foresight/lang/for-range/for_range.go

package main

import (
    "fmt"
    "sync"
)

func main() {
    sl := []int{11, 12, 13, 14, 15}
    var wg sync.WaitGroup
    for i, v := range sl {
        wg.Add(1)
        go func() {
            fmt.Printf("%d : %d\n", i, v)
            wg.Done()
        }()
    }
    wg.Wait()
}

我们分别用Go 1.22rc1和Go 1.21.0来运行上面这段代码:

// 使用go 1.22rc1的运行结果:

$go run for_range.go
4 : 15
1 : 12
0 : 11
3 : 14
2 : 13

// 使用go 1.21.0的运行结果:
$go run for_range.go
4 : 15
4 : 15
4 : 15
4 : 15
4 : 15

之所以存在差异,是因为Go 1.22版本开始,for range语句中声明的循环变量(比如这里的i和v)不再是整个loop一份(loop var per loop),而是每次iteration都会有自己的变量(loop var per-iteration),这样在Go 1.22中,for range中的goroutine启动的闭包函数中捕获的变量是loop var per-iteration,这样才会输出5个不同的索引值和对应的切片值。

注:关于Go 1.22版本之前的for range的坑,《Go语言第一课》专栏有图文并茂的原理讲解,欢迎订阅阅读。

那传统的3-clause的for loop呢?其中的循环变量的语义是否也发生变化了呢?我们看下面示例:

// go1.22-foresight/lang/for-range/classic_for_loop.go

package main

import (
    "fmt"
    "sync"
)

func main() {
    sl := []int{11, 12, 13, 14, 15}
    var wg sync.WaitGroup
    for i := 0; i < len(sl); i++ {
        wg.Add(1)
        go func() {
            v := sl[i]
            fmt.Printf("%d : %d\n", i, v)
            wg.Done()
        }()
    }
    wg.Wait()
}

我们依然分别用Go 1.22rc1和Go 1.21.0版本运行这段代码,得到的结果如下:

// 使用go 1.22rc1的运行结果:

$go run classic_for_loop.go
0 : 11
4 : 15
2 : 13
3 : 14
1 : 12

// 使用go 1.21.0的运行结果:

$go run classic_for_loop.go
panic: runtime error: index out of range [5] with length 5

goroutine 20 [running]:
main.main.func1()
    /Users/tonybai/test/go/go1.22-foresight/lang/for-range/classic_for_loop.go:14 +0xc9
created by main.main in goroutine 1
    /Users/tonybai/test/go/go1.22-foresight/lang/for-range/classic_for_loop.go:13 +0x7f
panic: runtime error: index out of range [5] with length 5

goroutine 19 [running]:
main.main.func1()
    /Users/tonybai/test/go/go1.22-foresight/lang/for-range/classic_for_loop.go:14 +0xc9
created by main.main in goroutine 1
    /Users/tonybai/test/go/go1.22-foresight/lang/for-range/classic_for_loop.go:13 +0x7f
exit status 2

从输出结果来看,3-clause的for语句中声明的循环变量也变成了loop var per-iteration了。

在Go 1.22之前,go vet工具在遇到像上面代码那样在闭包中引用循环变量的情况时会给出警告,但由于Go 1.22的这个语义修正,go vet对于Go 1.22及以后版本(根据go.mod中的指示)的类似Go代码将不再报错。

不过就像Russ Cox在spec: less error-prone loop variable scoping这一issue中提及那样,该特性落地可能会带来不兼容问题,即对存量代码行为的破坏性改变。为此Go团队提供了一个名为bisect的工具,该工具可以检测出存量代码在for loop语义发生变更后是否会导致问题。不过该工具似乎只能与go test一起使用,也就是说你只能对那些被Go测试覆盖到的for loop进行检测。

目前spec: less error-prone loop variable scoping这一issue还处于open状态,也没有放入Go 1.22 milestone中,不知道后续是否还会存在变数!

1.2 range支持整型表达式

在Go 1.22版本中,for range后面的range表达式除了支持传统的像数组、切片、map、channel等表达式外,还支持放置整型表达式,比如下面这个例子:

// lang/range-expr-support-integer/main.go

func main() {
    n := 5
    for i := range n {
        fmt.Println(i)
    }
}

我们知道:for range会在执行伊始对range表达式做一次求值,这里对n求值结果为5。按照新增的for range后接整型表达式的语义,对于整数值n,for range每次迭代值会从0到n-1按递增顺序进行。上面代码中的for range会从0迭代到4(5-1),我们执行一下上述代码就可以印证这一点:

$go run main.go
0
1
2
3
4

如果n <= 0,则循环不运行任何迭代。

这个新语法特性,可以理解为是一种“语法糖”,是下面等价代码的“语法糖”:

for i := 0; i < 5; i++ {
    fmt.Println(i)
}

不过,迭代总是从0开始,似乎限制了该语法糖的使用范围。

1.3 试验特性:range-over-function iterators

在for range支持整型表达式的时候,Go团队也考虑了增加函数迭代器(iterator),不过前者语义清晰,实现简单。后者展现形式、语义和实现都非常复杂,于是在Go 1.22中,函数迭代器以试验特性提供,通过GOEXPERIMENT=rangefunc可以体验该功能特性。

在没有函数迭代器之前,我们实现一个通用的反向迭代切片的函数可能是像这样:

// lang/range-over-function-iterator/backward_iterate_slice_old.go

func Backward(s []E) func(func(int, E) bool) {
    return func(yield func(int, E) bool) {
        for i := len(s)-1; i >= 0; i-- {
            if !yield(i, s[i]) {
                return
            }
        }
        return
    }
}

下面是在Go 1.21.0版本中使用上面Backward函数的方式:

// lang/range-over-function-iterator/backward_iterate_slice_old.go

func main() {
    sl := []string{"hello", "world", "golang"}
    Backward(sl)(func(i int, s string) bool {
        fmt.Printf("%d : %s\n", i, s)
        return true
    })
}

我们用Go 1.21.0运行一下上述示例:

$go run backward_iterate_slice_old.go
2 : golang
1 : world
0 : hello

在以前版本中,这种对切片、数组或map中进行元素迭代的情况在实际开发中非常常见,也比较模式化,但基于目前语法,使用起来非常不便。于是Go团队提出将它们与for range结合在一起的提案。有了range-over-function iterator机制后,我们就可以像下面这样使用Backward泛型函数了:

// lang/range-over-function-iterator/backward_iterate_slice_new.go

func main() {
    sl := []string{"hello", "world", "golang"}
    for i, s := range Backward(sl) {
        fmt.Printf("%d : %s\n", i, s)
    }
}

相比于上面的老版本代码,这也的代码更简洁清晰了,使用Go 1.22rc1的运行结果也与老版本别无二致:

$GOEXPERIMENT=rangefunc  go run backward_iterate_slice_new.go
2 : golang
1 : world
0 : hello

但代价就是要理解什么样原型的函数才能与for range一起使用实现函数迭代,这的确有些复杂,本文就不展开说了,有兴趣的童鞋可以先看看有关range-over-function iterator的wiki先行了解一下。

2. 编译器、运行时与工具链

2.1 继续增强PGO优化

Go 1.20版本引入PGO(profile-guided optimization)后,PGO这种优化技术带来的优化效果就得到了持续的提升:Go 1.20实测性能提升仅为1.05%;Go 1.21版本发布时,官方的数据是2%~7%,而Go 1.21编译器自身在PGO优化过后编译速度提升约6%。

在Go 1.22中,官方给出的数字则是2%~14%,这14%的提升想必是来自Google内部的某个实际案例。

2.2 inline和devirtualize

在Go 1.22中,Go编译器可以更灵活的运用devirtualize和inline对代码进行优化了。

在面向对象的编程中,虚拟函数是一种在运行时动态确定调用的函数。当调用虚拟函数时,编译器通常会为其生成一段额外的代码,用于在运行时确定要调用的具体函数。这种动态调度的机制使得程序可以根据实际对象类型来执行相应的函数,但也带来了一定的性能开销。通过devirtualize优化技术,编译器会尝试在编译时确定调用的具体函数,而不是在运行时进行动态调度。这样可以避免运行时的开销,并允许编译器进行更多的优化

对应到Go来说,就是在编译阶段将使用接口进行的方法调用转换为通过接口的实际类型的实例直接调用该方法

注:我的《Go语言精进之路》一书中有对通过接口调用方法的原理的详尽说明,欢迎阅读。

关于内联优化,今年Austin Clements发起了inline大修项目,对Go编译器中的内联优化过程进行全面调整,目标是在Go 1.22中拥有更有效的、具有启发能力的内联,为后续内联的进一步增强奠定基础。该大修的成果目前以GOEXPERIMENT=newinliner试验特性的形式在Go 1.22中提供。

2.3 运行时

运行时的变化主要还是来自GC

Go 1.22中,运行时会将基于类型的垃圾回收的元数据放在每个堆对象附近,从而可以将Go程序的CPU性能提高1-3%。同时,通过减少重复的元数据的优化,内存开销也将降低约1%。不确定减少重复元数据(metadata)这一优化是否来自对unique包的讨论

2.4 工具链

在Go工具链改善方面,首当其冲的要数go module相关工具了。

在Go 1.22中,go work增加了一个与go mod一致的特性:支持vendor。通过go work vendor,可以将workspace中的依赖放到vendor目录下,同时在构建时,如果module root下有vendor目录,那么默认的构建是go build -mod=vendor,即基于vendor的构建。

go mod init在Go 1.22中将不再考虑GOPATH时代的包依赖工具的配置文件了,比如Gopkg.lock。在Go 1.22版本之前,如果go module之前使用的是类似dep这样的工具来管理包依赖,go mod init会尝试读取dep配置文件来生成go.mod。

go vet工具取消了对loop变量引用的警告,增加了对空append的行为的警告(比如:slice = append(slice))、增加了deferring time.Since的警告以及在log/slog包的方法调用时key-value pair不匹配的警告。

3. 标准库

最后,我们来看看标准库的变化。每次Go发布新版本,标准库都是占更新的大头儿,这里无法将所有变更点一一讲解,仅说说几个重要的变更点。

3.1 增强http.ServerMux表达能力

Go内置电池,从诞生伊始就内置了强大的http库,不过长期以来http原生的ServeMux表达能力比较单一,不支持通配符等,这也是Go社区长期以来一直使用像gorilla/muxhttprouter等第三方路由库的原因。

今年log/slog的作者Jonathan Amsterdam又创建了新的提案:net/http: enhanced ServeMux routing,提高http.ServeMux的表达能力。在新提案中,新的ServeMux将支持如下路由策略(来自http.ServeMux的官方文档):

  • “/index.html”路由将匹配任何主机和方法的路径”/index.html”;
  • “GET /static/”将匹配路径以”/static/”开头的GET请求;
  • “example.com/”可以与任何指向主机为”example.com”的请求匹配;
  • “example.com/{$}”会匹配主机为”example.com”、路径为”/”的请求,即”example.com/”;
  • “/b/{bucket}/o/{objectname…}”匹配第一段为”b”、第三段为”o”的路径。名称”bucket”表示第二段,”objectname”表示路径的其余部分。

下面就是基于上面的规则编写的示例代码:

// lib/servemux/main.go

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/index.html", func(w http.ResponseWriter, req *http.Request) {
        fmt.Fprintln(w, `match /index.html`)
    })
    mux.HandleFunc("GET /static/", func(w http.ResponseWriter, req *http.Request) {
        fmt.Fprintln(w, `match "GET /static/"`)
    })
    mux.HandleFunc("example.com/", func(w http.ResponseWriter, req *http.Request) {
        fmt.Fprintln(w, `match "example.com/"`)
    })
    mux.HandleFunc("example.com/{$}", func(w http.ResponseWriter, req *http.Request) {
        fmt.Fprintln(w, `match "example.com/{$}"`)
    })
    mux.HandleFunc("/b/{bucket}/o/{objectname...}", func(w http.ResponseWriter, req *http.Request) {
        bucket := req.PathValue("bucket")
        objectname := req.PathValue("objectname")
        fmt.Fprintln(w, `match /b/{bucket}/o/{objectname...}`+":"+"bucket="+bucket+",objectname="+objectname)
    })

    http.ListenAndServe(":8080", mux)
}

我们使用curl对上述示例进行一个测试(前提是在/etc/hosts中设置example.com为127.0.0.1):

$curl localhost:8080/index.html
match /index.html

$curl example.com:8080/static/abc
match "example.com/"

$curl localhost:8080/static/abc
match "GET /static/"

$curl example.com:8080/
match "example.com/{$}"

$curl example.com:8080/b/mybucket/o/myobject/tonybai
match "example.com/"

$curl localhost:8080/b/mybucket/o/myobject/tonybai
match /b/{bucket}/o/{objectname...}:bucket=mybucket,objectname=myobject/tonybai

从测试情况来看,不同路由设置之间存在交集,这就需要路由匹配优先级规则。新版Go ServeMux规定:如果一个请求有两个或两个以上的模式匹配,则更具体(specific)的模式优先。如果P1符合P2请求的严格子集,也就是说,如果P2符合P1及更多的所有请求,那么P1就比P2更具体。

举个例子:”/images/thumbnails/”比”/images/”更具体,因此两者都可以注册。前者匹配以”/images/thumbnails/”开头的路径,后者则匹配”/images/”子树中的任何其他路径。

如果两者都不更具体,那么模式就会发生冲突。为了向后兼容,这一规则有一个例外:如果两个模式发生冲突,而其中一个模式有主机(host),另一个没有,那么有主机的模式优先(比如上面测试中的第二次curl执行)。如果通过ServeMux.Handle或ServeMux.HandleFunc设置的模式与另一个已注册的模式发生冲突,这些函数就会panic。

增强后的ServeMux可能会影响向后兼容性,使用GODEBUG=httpmuxgo121=1可以保留原先的ServeMux行为。

3.2 增加math/rand/v2包

在日常开发中,我们多会在生成随机数的场景下使用math/rand包,其他时候使用的较少。但Go 1.22中新增了math/rand/v2包,我之所以将这个列为Go 1.22版本标准库的一次重要变化,是因为这是标准库第一次为某个包建立v2版本包,按照Russ Cox的说法,这次v2包的创建,为标准库中的其他可能的v2包树立了榜样。创建math/rand/v2可以使Go团队能够在一个相对不常用且风险较低的包中解决工具问题(如gopls、goimports等对v2包的支持),然后再转向更常用、风险更高的包,如sync/v2或encoding/json/v2等。

新增rand/v2包的直接原因是清理math/rand并修复其中许多悬而未决的问题,特别是使用过时的生成器、慢速算法以及与crypto/rand冲突的问题,这里就不针对v2包举具体的示例了,对该包感兴趣的同学可以自行阅读该包的在线文档,并探索如何使用v2包。

同时,该提案也为标准库中的v2包的创建建立了一种模式,即v2包是原始包的子目录,并且以原始包的API为起点,每个偏离点都要有明确的理由。

想当初,go module刚落地到Go中时,Go module支持两种识别major的两种方式,一种是通过branch或tag号来识别,另外一种就是利用vN目录来定义新包。当时还不是很理解为什么要有vN目录这种方式,现在从math/rand/v2包的增加来看,足以体现出当初module设计时的前瞻性考量了。

3.3 大修Go execution tracer

Go Execution Tracer是解决Go应用性能方面“疑难杂症”的杀手锏级工具,它可以提供Go程序在一段时间内发生的情况的即时视图。这些信息对于了解程序随时间推移的行为非常宝贵,可辅助开发人员对应用进行性能改进。我曾在《通过实例理解Go Execution Tracer》中对其做过系统的说明。

不过当前版本的Go Execution Tracer在原理和使用方面还存在诸多问题,Google的Michael Knyszek在年初发起了Execution tracer overhaul的提案,旨在对Go Execution Tracer进行改进,使Go Execution Tracer可扩展到大型Go部署的Go执行跟踪。具体目标如下:

  • 使跟踪解析所需的内存占用量仅为当前的一小部分。
  • 支持可流式传输的跟踪,以便在无需存储的情况下进行分析。
  • 实现部分自描述的跟踪,以减少跟踪消费者的升级负担。
  • 修复长期存在的错误,并提供一条清理实现的路径。

在近一年的时间里,Knyszek与Felix Geisendorfer、Nick Ripley、Michael Pratt等一起实现了该提案的目标。

鉴于篇幅,这里就不对新版Tracer的使用做展开说明,有兴趣的童鞋可结合《通过实例理解Go Execution Tracer》中的使用方法自行体验新版Tracer。

注:新版Tracer的设计文档 – https://go.googlesource.com/proposal/+/ac09a140c3d26f8bb62cbad8969c8b154f93ead6/design/60773-execution-tracer-overhaul.md

3.4 其他

Go 1.4版本以来,syscall包新特性就已经被冻结,并在Go 1.11版本中被标记为不推荐使用(deprecate)。Go团队推荐gopher使用golang.org/x/sys/unix或golang.org/x/sys/windows。syscall包的大多数功能都能被golang.org/x/sys包替代,除了下面这几个:

syscall.SysProcAttr(类型os/exec.Cmd.SysProcAttr)
syscall.Signal(参考文献os.Signal)
syscall.WaitStatus(参考文献os.(*ProcessState).Sys)
syscall.Stat_t
... ...

由于syscall包已经弃用,IDE等工具在开发人员使用上述内容时总是得到警告!这引发了众多开发人员的抱怨。为此,在Go 1.22版本中,syscall取消了弃用状态,但其功能特性依旧保持冻结,不再添加新特性。

  • TCPConn to UnixConn:支持zerocopy

gnet作者Andy Pan的提案:TCPConn to UnixConn:支持zerocopy在Go 1.22落地,具体内容可以看一下原始提案issue

  • 新增go/version包

在Go 1.21版本发布后,Go团队对Go语言的版本规则做了调整,并明确了Go语言的向前兼容性和toolchain规则,Go 1.22中增加go/version包实现了按照上述版本规则的Go version判断,这个包既用于go工具链,也可以用于Gopher自行开发的工具中。

4. 小结

Go 1.22版本具有至少两点重要的里程碑意义:

  • 通过对loopvar语义的修正,开启了Go已有“语法坑”的fix之路
  • 通过math/rand/v2包树立了Go标准库建立vN版本的模式

“语法坑”fix是否能得到社区正向反馈还是一个未知数,其导致的兼容性问题势必会成为Go社区在升级到Go 1.22版本的重要考虑因素,即便决定升级到Go 1.22,严格的代码审查和测试也是必不可少的。

最后,感谢Go团队以及所有Go 1.22贡献者做出的伟大工作!

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

5. 参考资料

-Go 1.22 Milestone – https://github.com/golang/go/milestone/298


“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

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

通过实例理解OpenID身份认证

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

在《通过实例理解OAuth2》一文中,我们以实例方式讲解了OAuth2授权码模式(Authorization Code)模式的工作原理。实例中的照片冲印服务经过用户(tonybai)的授权后,使用用户提供的code(实则是由授权服务器分配并通过用户的浏览器重定向到照片冲印服务的)到授权服务器换取了access token,并最终使用access token从云盘系统中读取到了用户的照片信息。

不过,拿到了access token的照片冲印服务并不知道这个access token代表的是云盘服务上的哪个用户,要不是云盘服务在照片list接口返回了用户名(tonybai),照片冲印服务还需要自己为授权给它的用户创建一个临时的用户id标识。当tonybai用户一周后再次访问照片冲印服务时,照片冲印服务还需要再走一次OAuth2授权流程,这对用户的体验并不好。

从照片冲印服务角度来说,它希望在用户第一次使用服务并授权时,就能得到用户身份信息,将用户加入到自己的用户体系中,并通过类似基于会话的身份认证机制在用户后续使用服务时自动识别并认证用户身份。这样,既可以避免用户额外单独注册账号的不佳体验,又可以避免用户下次使用服务时繁琐地授权过程。

然而,尽管OAuth 2.0是一个需要用户交互的安全协议,但它终归不是身份认证协议。但很多像照片冲印服务这样的应用还有通过像云盘系统这一的大厂应用进行用户身份认证的强烈需求,于是有很多厂商都制定了各自专用的标准,比如Facebook、Twitter、LinkedIn和GitHub等,但这些都是专用协议,缺乏标准性,开发者要逐一开发和适配。

于是OpenID基金会基于OAuth2.0制定了OpenID Connect(简称OIDC)这样的开放身份认证协议标准,可以在不同厂商之间通用。

在这篇文章中,我们就来介绍一下基于OpenID的身份认证原理,有了上一篇OAuth2做铺垫,OIDC理解起来就非常容易了。

1. OpenID Connect(OIDC)简介

OpenID Connect是一个开放标准,由OpenID基金会于2014年2月发布。它定义了一种使用OAuth 2.0执行用户身份认证的互通方式。由于该协议的设计具有互通性,一个OpenID客户端应用可以使用同一套协议语言与不同的身份提供者交互,而不需要为每一个身份提供者实现一套有细微差别的协议。OpenID Connect直接基于OAuth 2.0构建,并保持了OAuth2.0的兼容性。现实世界中,在多数情况下,OIDC都会与保护其他API的OAuth基础架构部署在一起。

我们在学习OAuth 2.0时,首先了解了该协议涉及的几个实体,如Client、Authorization Server、Resource Server、Resource owner、Protected resouce等,以及它们的交互流程。知道了这些也就掌握了OAuth2的内核。以此为鉴,我们学习OIDC协议,也从了解都有哪些实体参与了协议交互,以及它们的具体交互流程开始。

OpenID Connect是一个协议套件(OpenID Connect Protocol Suite),涉及Core、Discovery、Dynamic Client Registration等:

不过这里我们仅聚焦OpenID Connect的core 1.0协议规范

就像OAuth2.0支持四种授权模式一样,OIDC基于这四种模式,整合出了三种身份认证类型:

  • Authentication using the Authorization Code Flow
  • Authentication using the Implicit Flow
  • Authentication using the Hybrid Flow

其中Authentication using the Authorization Code Flow这种基于OAuth2授权码流程的身份认证方案应该是使用最为广泛的,本文也将基于这个流程对OIDC进行理解,并赋以实例。

1.1 OIDC协议中的实体与交互流程图

下面是OIDC规范中给出的通用的身份认证流程图,这个图是高度抽象的,适合上面三个flow:

通过这个图,我们先来认识参与OIDC流程中的三个实体:

  • RP(Relying Party)

图的最左端是一个叫RP的实体,如果对应到OAuth2.0那篇文章中的示例,这个RP对应的就是示例中的照片冲印服务,也就是OAuth2.0中的Client,即需要用户(EU)授权的那个实体。

  • OP(OpenID Provider)

OP对应的是OAuth2.0中的Authorization Server+Resource Server,不同的是在OIDC这个特殊场景下,Resource Server中存储的resource就是用户的身份信息

  • EU(End User)

EU,顾名思义就是使用RP服务的用户,它对应OAuth2.0中的Resource Owner。

结合这些实体、上面的抽象流程图以及OAuth2授权码模式的交互图,我画一下OIDC基于授权码模式进行身份认证的实体间的交互图,这里我们依旧以用户使用照片冲印服务为例:

上图就是一个基于授权码流程的OIDC协议流程,是不是赶脚跟OAuth 2.0中的授权码模式的流程几乎完全一致啊!

唯一的区别就是授权服务器(OP)在返回access_token的同时,还多返回了一个ID_TOKEN,我们称这个ID_TOKEN为ID令牌,这个令牌是OIDC身份认证的关键。

1.2 ID_TOKEN的组成

从上图中,我们看到ID_TOKEN与普通的OAuth access_token一起提供给Client(RP)使用,与access_token不同的是,RP是需要对ID_TOKEN进行解析的。那么这个ID_TOKEN究竟是什么呢?在OIDC协议中,ID_TOKEN是一个经过签名的JWT

OIDC协议规范规定了该jwt应该包含的字段信息,包括必选的(REQUIRED)与可选的(OPTIONAL),在这里我们了解下面的必选字段信息即可:

  • iss

令牌的颁发者,其值就是身份认证服务(OP)的URL,比如:http://open.my-yunpan.com:8081/oauth/token,不包含问号作为前缀的查询参数等。

  • sub

令牌的主题标识符,其值是最终用户(EU)在身份认证服务(OP)内部的唯一且永不重新分配的标识符。

  • aud

令牌的目标受众,其值是Client(RP)的标识,必须包含RP的OAuth 2.0客户端ID(client_id),也可以包含其他受众的标识符。

  • exp

过期时间,过期后ID_TOKEN将会失效。其值是一个JSON number,表示从1970-01-01T0:0:0Z开始(以 UTC 度量)到过期日期/时间为止的秒数。

  • iat

认证时间,即版本ID_TOKEN的时间,其值是一个JSON number,表示从1970-01-01T0:0:0Z开始(以 UTC 度量)到认证日期/时间为止的秒数。

注:如果客户端(RP)向身份认证服务器(OP)注册过公钥,则可以使用客户端公钥对该JWT进行非对称签名校验,或者可以使用客户端密钥对该JWT进行对称签名。这种方式可以提高客户端的安全等级,因为可以避免在网络上传递密钥。

在上面图中使用access_token获取user_info的环节中,RP可以通过ID_TOKEN中的sub(EU唯一标识符)到授权服务器的userinfo端点换取用户的基本信息,这样在RP自己的页面上展示EU的标识时就不可以不用9XDF-AABB-001ACFE这样的唯一标识符(sub),而是用TonyBai这样的可理解的字符串了。

注:OpenID Connect使用一个特殊的权限范围值openid来控制对UserInfo端点的访问。OpenID Connect定义了一组标准化的OAuth权限范围,对 应于用户属性的子集,比如profile 、email 、phone 、address等。

了解了OIDC的身份认证流程以及ID_TOKEN的组成后,我们就算对OIDC有个直观的认知了,接下来我们用一个实例来加深一下对OIDC身份认证的理解。

2. OIDC实例

如果你理解了《通过实例理解OAuth2》一文中的实例,那么理解本篇文章中的OIDC实例将是轻而易举的事情。前面说过,OIDC建构在OAuth2之上,与OAuth2兼容,因此,这里的OIDC实例也改自OAuth2一文中的实例。

与OAuth2一文实例相比,OIDC实例中去掉了云盘服务(my-yunpan),仅保留了下面结构:

$tree -L 2 -F oidc-examples
oidc-examples
├── my-photo-print/
│   ├── go.mod
│   ├── go.sum
│   ├── home.html
│   ├── main.go
│   └── profile.html
└── open-my-yunpan/
    ├── go.mod
    ├── go.sum
    ├── main.go
    └── portal.html

其中my-photo-print是照片冲印服务,也是oidc实例中的RP实体,而open-my-yunpan扮演着云盘授权服务,是oidc实例中的OP实体。在编写和运行服务之前,我们同样要先修改一下本机(MacOS或Linux)的/etc/hosts文件:

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

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

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

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

这与OAuth2一文中的实例并无什么差别,该页面也是由my-photo-print/main.go中的homeHandler提供的,它的home.html渲染模板也基本没有变化,因此这里就不赘述了。

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

2.2 使用open.my-yunpan.com进行授权,包括openid权限

云盘授权服务的首页还是“老样子”,唯一的差别就是请求的权限包含了一项openid(有my-photo-print的home.html带过来的):

这个页面同样由open.my-yunpan.com的portalHandler提供,它的逻辑与oauth2的实例相比没有变化,这里也罗列其代码了。

当用户(EU)填写用户名和密码后,点击“授权”,浏览器便会向云盘授权服务的”/oauth/authorize”发起post请求以获取code,负责”/oauth/authorize”端点的authorizeHandler会对用户进行身份认证,通过后,它会分配code并向浏览器返回重定向的应答,重定向的地址就是照片冲印服务的回调地址:http://my-photo-print.com:8080/cb?code=xxx&state=yyy。

2.3 获取access token以及id_token,并用用户唯一标识获取用户基本信息(profile)

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

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

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

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

    // check 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 and id_token with code
    accessToken, idToken, err := fetchAccessTokenAndIDToken(code)
    if err != nil {
        fmt.Println("fetch access_token error:", err)
        return
    }
    fmt.Println("fetch access_token ok:", accessToken)

    // parse id_token
    mySigningKey := []byte("iamtonybai")
    claims := jwt.RegisteredClaims{}
    _, err = jwt.ParseWithClaims(idToken, &claims, func(token *jwt.Token) (interface{}, error) {
        return mySigningKey, nil
    })
    if err != nil {
        fmt.Println("parse id_token error:", err)
        return
    }

    // use access_token and userID to get user info
    up, err := getUserInfo(accessToken, claims.Subject)
    if err != nil {
        fmt.Println("get user info error:", err)
        return
    }
    fmt.Println("get user info ok:", up)

    mu.Lock()
    userProfile[claims.Subject] = up
    mu.Unlock()

    // 设置cookie
    cookie := http.Cookie{
        Name:   "my-photo-print.com-session",
        Value:  claims.Subject,
        Domain: "my-photo-print.com",
        Path:   "/profile",
    }
    http.SetCookie(w, &cookie)
    w.Header().Add("Location", "/profile")
    w.WriteHeader(http.StatusFound) // redirect to /profile
}

这个handler中做了很多工作。首先是使用code像授权服务器换取access token和id_token,授权服务器负责颁发token的是tokenHandler:

// oidc-examples/open-yunpan/main.go

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

    // check client_id and client_secret
    user, password, ok := r.BasicAuth()
    if !ok {
        fmt.Println("no authorization header")
        w.WriteHeader(http.StatusNonAuthoritativeInfo)
        return
    }

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

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

    // check code and redirect_uri
    code := r.FormValue("code")
    redirect_uri := r.FormValue("redirect_uri")

    mu.Lock()
    ac, ok := codeCache[code]
    if !ok {
        fmt.Println("not found code:", code)
        mu.Unlock()
        w.WriteHeader(http.StatusNotFound)
        return
    }
    mu.Unlock()

    if ac.redirectURI != redirect_uri {
        fmt.Println("invalid redirect_uri:", redirect_uri)
        w.WriteHeader(http.StatusBadRequest)
        return
    }

    var authResponse struct {
        AccessToken string `json:"access_token"`
        IDToken     string `json:"id_token,omitempty"`
        ExpireIn    int    `json:"expires_in"`
    }

    // generate access_token
    authResponse.AccessToken = randString(16)
    authResponse.ExpireIn = 3600
    now := time.Now()
    expired := now.Add(10 * time.Minute)
    claims := jwt.RegisteredClaims{
        Issuer:    "http://open.my-yunpan.com:8091/oauth/token",
        Subject:   ac.userID,
        Audience:  jwt.ClaimStrings{user}, //client_id
        IssuedAt:  &jwt.NumericDate{now},
        ExpiresAt: &jwt.NumericDate{expired},
    }

    if strings.Contains(ac.scopeTxt, "openid") {
        // generate id_token if contains openid
        mySigningKey := []byte("iamtonybai")
        jwtToken := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)
        authResponse.IDToken, _ = jwtToken.SignedString(mySigningKey)
    }

    respData, _ := json.Marshal(&authResponse)
    w.Write(respData)
}

我们看到tokenHandler先是对客户端(client)凭据做了校验,接下来验证code,如果code通过验证,则会分配access_token,并根据scope中是否包含openid决定是否分配id_token,这里我们的权限授权中包含了openid,于是tokenHandler将id_token(一个jwt)一并生成并返回给client。

而拿到access_token和id_token的my-photo-print的oauthCallbackHandler会解析id_token,提取其中的有效信息,比如subject等,并用access_token和id_token中的subject(用户的唯一ID)去授权服务获取用户(EU)的基础身份信息(姓名、主页、邮箱等),并将用户的唯一ID作为cookie存入用户的浏览器。最后让浏览器重定向到my-photo-print的profile页面。

请注意:这里仅是为了简便起见,生产环境请考虑更为安全的会话机制。

profile页面的处理函数为profileHandler:

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

// user profile页面
func profileHandler(w http.ResponseWriter, r *http.Request) {
    fmt.Println("profileHandler:", *r)

    cookie, err := r.Cookie("my-photo-print.com-session")
    if err != nil {
        http.Error(w, "找不到cookie,请重新登录", 401)
        return
    }
    fmt.Printf("found cookie: %#v\n", cookie)

    mu.Lock()
    pf, ok := userProfile[cookie.Value]
    if !ok {
        mu.Unlock()
        fmt.Println("not found user:", cookie.Value)
        // 跳转到首页
        http.Redirect(w, r, "/", http.StatusSeeOther)
        return
    }
    mu.Unlock()

    // 渲染照片页面模板
    tmpl := template.Must(template.ParseFiles("profile.html"))
    tmpl.Execute(w, pf)
}

我们看到:该handler首先查找cookie中是否存在用户ID,如果不存在,则重定向到登录页面,如果存在,则取出用户唯一ID,并使用该ID查找用户profile信息,最后展示到web页面上:

到这里,我们看到:这种委托云盘授权服务对my-photo-print的用户进行身份认证并拿到该用户基本信息的机制,就是oidc。

注:一旦拿到云盘授权服务身份认证后的用户信息,RP便可以使用各种身份认证机制来管理EU用户,比如RP可以使用会话管理技术(例如使用会话标识符或浏览器cookie)来跟踪EU的会话状态。如果EU在同一会话期间访问RP应用,RP可以通过会话标识符来识别EU,而无需再次进行身份验证。

3. 小结

通过上面的内容,我们对OpenID Connect(OIDC)有了更直观的理解,这里做一个小结:

  • OIDC是一套身份认证的开放标准协议,基于OAuth 2.0构建,与OAuth 2.0兼容。
  • OIDC协议中主要涉及三个角色:RP(依赖方)、OP(身份提供方)、EU(最终用户)。
  • EU通过RP使用OP进行身份认证后,RP可以获得EU的身份信息。整个流程与OAuth 2.0的授权码流程高度相似。
  • 关键的差别在于:OP返回的token中除了access_token外,还包含一个ID_TOKEN(JWT格式)。
  • RP通过解析ID_TOKEN可以获得EU的唯一标识等信息,并通过access_token进一步获取EU的详细身份信息。
  • RP获得EU身份信息后,可以通过各种机制识别和管理EU,无需EU重复身份验证。

总的来说,OIDC利用OAuth 2.0流程进行身份认证,通过额外返回的ID_TOKEN提供EU身份信息,很好地满足了RP对EU身份管理的需求。

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

4. 参考资料


“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