五一期间在flomo官网的扩展中心看到了这个Raycast to flomo，对mac上的效率工具有了点了解，我直接基本都没有用过Mac自带的spotlight。。。

我好奇的不是竟然可以用这种方式发送到flomo，毕竟官网API摆在那，调一下也很简单，我惊奇的是Raycast跟Mac系统的风格比较搭配，看上去不错，就去Raycast的官网看了一下。

缘起

看了下Raycast的API文档，妥妥的对前端开发及其友好啊，大赞！

文档撸了一遍之后，我看到自己感兴趣的Auth部分。

用官网的demo试了试twitter的oauth pkce登录流程，很顺畅，瞬间有了一种想给道招网也安排上，虽然本站基本只有我一个人会登录，很多年前我就把注册功能给禁用了，这次准备开放了。

自己顺便了解了一下PKCE流程

上图来自auth0.com

原来PKCE是为了优化现在流行的SPA应用token验证流程的。

OAuth2.0

先回顾下OAuth2.0流程：

在获取token的时候需要提供如下信息：

1. code
2. redirect_url
3. client_id, client secret

第二项和第三项其实是用来对通过code获取token的client的合法性进行验证。其中最核心的应该是client secret。通过它可以解决如下问题：

对获取token的client进行合法性验证。secret是在Authorization Server上注册client的时候设置的，只有client自己知道，因此可以对client进行验证。

这样的话，即使code因为某种原因泄露了，没有secret也无法获取到token。从而提升了安全性。在传统的Web应用中，token的获取是发生在后端，因此secret也是保存在后端。这样是可行的。但是对于现在比较流行的SPA应用，token的获取是发生在浏览器端，是一个公开的环境。这个方法就不可行了，因为secret不可能保存在一个公开的环境中。

PKCE

PKCE主要是通过在授权的过程中增加了code_challenge和code_verifier两个元素来对整个流程进行验证，防止code被第三方截取的情况。具体流程如下：

这里面最核心的其实就是在authorize请求中增加了code_challenge参数，在token请求中增加了code_verifier参数。这两个参数最终都是依赖于一个client生成的随机字符串。

• codeverifier：一个Client端生成的随机字符串（由字母，数字，- ，. ， ，~ 组成）
• code_challenge：由code_verifier生成的字符串。 生成算法为：BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))。

过程解析：

1. 在申请授权时（authorize请求）,client将code_challenge传给authorization server.(这个过程中code_verifier在网络中不会被暴露，因为对其进行了hash)。
2. authorization server生成授权码后，会将code_challenge保存起来，并与授权码关联。
3. 在通过授权码获取token的过程中，client会将code_verifier传给authorization server
4. authorization server会将code_verifier按照第一步相同算法计算得到新的code_challenge
5. authorization server将第四步计算得来的code_challenge与第一步中的原始code_challenge进行比较，如果相同则认为申请授权的源与用code获取token的源为同一来源。（即code没有被第三方截取而冒用）

客户端一般用oide-provider来对接PKCE。

参考文章

• Authorization Code Flow with Proof Key for Code Exchange (PKCE)
• 基于Identity Server4的OAuth 2.0授权总结（4）- PKCE in Authorization Code mode