Day12 - 【概念篇】OAuth flows: flows这一小段路上路前注意事项

本系列文之後也会置於个人网站

其实我原本是想要 RESTer 干到底的哈?。

今天有一点是插话的。考虑到接下来几天的内容，所使用到的工具会有点多样，所以行前做个提醒。

首先，你最好了解:

• HTTP Request / Response
• HTTP API (Web API)
• JSON
• BASE64

诺对於Postman这类工具有所熟悉再好不过。但接者几天会使用:

• RESTer
• curl
  有一些情况会直接使用。
• python
  主要用於格式化JSON。

除此之外，如果熟悉Bash的话同样也有助於理解所有内容。此外还有可能会使用到 OAuth Tools 、 jwt.io 。(JWT的部分更有可能出现在之後关於Open-Id内容前後)

但其实，以上并非全部都是必须。最重要的是希望你能够学习到OAuth本身的部分。

首先，起初的OAuth设计是基於HTTP的，但其实有相当多细节有多种方式实现。

接者，除了之前提到的客户端、资源拥有者、受保护的资源(资源服务器)外和授权服务器外，客户端又将拆分成前端客户端与後端客户端。
通常前端客户端指的是浏览器；而後端客户端是实际需要取得存取权杖(Access Token)的服务程序，通常也意味着其实是需要受保护的资源。
前端与後端有可能其实就是同一支程序；还有可能是不同程序外，更可以是没有直接关系的程序。简单整理一下：

• 资源拥有者/取用者:
  实际拥有资源，或已经拥有授权的使用者。在系统上是用户帐号，但通常指自然人。
• 前端客户端:
  要求用户进行验证授权。通常为浏览器。
• 後端客户端:
  实际执行业务逻辑、提供服务。需要取得存取权杖(Access Token)，进而存取受保护的资源。
• 资源服务器:
  管理、保护需受保护资源。
• 验证/授权服务器:
  验证资源拥有者，并提供存取权杖授权给客户端。

而通常的行为流程如下:

1. 资源拥有者 透过浏览器登入
2. 授权服务器 验证身分并确认授权
3. 授权给客户端
4. 客户端 取得受保护资源
5. 客户端 提供 资源拥有者 服务

RFC 6749的图：

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

                     Figure 1: Abstract Protocol Flow