又LAG隨性筆記
  • 關於我
  • 作品集
  • 生活隨筆
  • 與我聯絡
  • 隨手扎

隨手扎

May 16, 2022

【用Keycloak學習身份驗證與授權16】Refresh Token

  +--------+                                           +---------------+
  |        |--(A)------- Authorization Grant --------->|               |
  |        |                                           |               |
  |        |<-(B)----------- Access Token -------------|               |
  |        |               & Refresh Token             |               |
  |        |                                           |               |
  |        |                            +----------+   |               |
  |        |--(C)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(D)- Protected Resource --| Resource |   | Authorization |
  | Client |                            |  Server  |   |     Server    |
  |        |--(E)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(F)- Invalid Token Error -|          |   |               |
  |        |                            +----------+   |               |
  |        |                                           |               |
  |        |--(G)----------- Refresh Token ----------->|               |
  |        |                                           |               |
  |        |<-(H)----------- Access Token -------------|               |
  +--------+           & Optional Refresh Token        +---------------+

               Figure 2: Refreshing an Expired Access Token

   The flow illustrated in Figure 2 includes the following steps:

   (A)  The client requests an access token by authenticating with the
        authorization server and presenting an authorization grant.

   (B)  The authorization server authenticates the client and validates
        the authorization grant, and if valid, issues an access token
        and a refresh token.

   (C)  The client makes a protected resource request to the resource
        server by presenting the access token.

   (D)  The resource server validates the access token, and if valid,
        serves the request.

   (E)  Steps (C) and (D) repeat until the access token expires.  If the
        client knows the access token expired, it skips to step (G);
        otherwise, it makes another protected resource request.

   (F)  Since the access token is invalid, the resource server returns
        an invalid token error.

使用refresh_token取得access_token

接著是使用Refresh Token換取Access Token的流程。這大概是所有中最簡單的一個模式之一了。 但因爲先決條件是取得可用的 Refresh Token ,所以無法單獨存在。在RCF6749相關的流程圖中,關注的是G、H的部分。 至於一開始有什麼方式取得Refresh Token就非常的多。在已經介紹的密碼模式和code模式都有可能返回refresh_token。

May 16, 2022

【用Keycloak學習身份驗證與授權15】Authorization Code

     +----------+
     | Resource |
     |   Owner  |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier      +---------------+
     |         -+----(A)-- & Redirection URI ---->|               |
     |  User-   |                                 | Authorization |
     |  Agent  -+----(B)-- User authenticates --->|     Server    |
     |          |                                 |               |
     |         -+----(C)-- Authorization Code ---<|               |
     +-|----|---+                                 +---------------+
       |    |                                         ^      v
      (A)  (C)                                        |      |
       |    |                                         |      |
       ^    v                                         |      |
     +---------+                                      |      |
     |         |>---(D)-- Authorization Code ---------'      |
     |  Client |          & Redirection URI                  |
     |         |                                             |
     |         |<---(E)----- Access Token -------------------'
     +---------+       (w/ Optional Refresh Token)

   Note: The lines illustrating steps (A), (B), and (C) are broken into
   two parts as they pass through the user-agent.

                     Figure 3: Authorization Code Flow

Authorization Code是在 RFC6749第一個提到的流程,所以有時又被視爲 標準流程(Standard Flow) 。

它與前兩個流程很不一樣,分成 前端通訊(frontchannel) 和 後端通訊(Backchannel) 。不過,其實反倒是前兩個是所有模式裡的怪胎,在隱含模式下,後端通信並在前端通訊;在密碼模式下,根本不存在前端通信,資源擁有者需要高度信任客戶端(說穿了在前端通信下,資源擁有者也是高度信賴瀏覽器或代理(User-Agent))。

May 16, 2022

【用Keycloak學習身份驗證與授權14】Implicit (Legacy)


     +----------+
     | Resource |
     |  Owner   |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier     +---------------+
     |         -+----(A)-- & Redirection URI --->|               |
     |  User-   |                                | Authorization |
     |  Agent  -|----(B)-- User authenticates -->|     Server    |
     |          |                                |               |
     |          |<---(C)--- Redirection URI ----<|               |
     |          |          with Access Token     +---------------+
     |          |            in Fragment
     |          |                                +---------------+
     |          |----(D)--- Redirection URI ---->|   Web-Hosted  |
     |          |          without Fragment      |     Client    |
     |          |                                |    Resource   |
     |     (F)  |<---(E)------- Script ---------<|               |
     |          |                                +---------------+
     +-|--------+
       |    |
      (A)  (G) Access Token
       |    |
       ^    v
     +---------+
     |         |
     |  Client |
     |         |
     +---------+

   Note: The lines illustrating steps (A) and (B) are broken into two
   parts as they pass through the user-agent.

                       Figure 4: Implicit Grant Flow

如果說password適用於原生應用環境(Native Application)下的話,接著就是適用於純前端環境。 在現在前後分離架構的情況,前端與後端連接並不緊密,甚至前端幾乎就可以視爲一個完整的應用。 因此將前端視爲授權框架下的「客戶端(Client)」也就不會太難理解。

May 16, 2022

【用Keycloak學習身份驗證與授權13】Password Grant (Legacy)

首先,先來看看直接使用帳號密碼授權的。

是的, OAuth 是有一個模式支援直接使用帳號密碼的。 與萬能鑰匙不太一樣的是,授權的結果仍然是由授權伺服器的權杖和資源伺服器決定。 儘管透過中央授權控制可以限制存取權杖可以做些什麼,但畢竟直接使用帳號密碼並不是特別好, 故在其他模式下都不適用時,才應該再考慮此模式。


     +----------+
     | Resource |
     |  Owner   |
     |          |
     +----------+
          v
          |    Resource Owner
         (A) Password Credentials
          |
          v
     +---------+                                  +---------------+
     |         |>--(B)---- Resource Owner ------->|               |
     |         |         Password Credentials     | Authorization |
     | Client  |                                  |     Server    |
     |         |<--(C)---- Access Token ---------<|               |
     |         |    (w/ Optional Refresh Token)   |               |
     +---------+                                  +---------------+

            Figure 5: Resource Owner Password Credentials Flow

事前準備

安裝RESTer

May 16, 2022

【用Keycloak學習身份驗證與授權12】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本身的部分。

May 16, 2022

【用Keycloak學習身份驗證與授權11】OAuth 2

終於要來談談OAuth裡定義的細節了~

目前OAuth 2.0 一共定義了7種流程(flow)。在未來本系列可能稱之爲模式,不同模式適用於不同情況、不同環境。 就是因爲如此,OAuth才有高彈性的優勢。

OAuth 2.0 的可擴展性和模塊化是其最大的優勢之一,因為這使得該協議適用於各種環境。然而,正是這種靈活性導致不同的實現之間存在基本的相容性問題。當開發人員想在不同的系統上實現 OAuth 時,它提供的眾多自定義選項容易使人困惑。

本系列會介紹的模式包含:

  1. Password Grant (密碼模式)
  2. Implicit (隱含模式)
  3. Authorization Code (Code模式)
  4. Refresh Token
  5. Client Credentials (特殊密碼模式)
  6. PKCE
  7. Device Code

儘管 Implicit 和 Password Grant 被標記爲傳奇的(Legacy),但有時候仍然可能會使用到。重要的是你應該知道什麼情況應該使用什麼模式。同時記住,即使一個系統按照規範正確地實現了 OAuth,也不意味著該系統在實踐中就是安全的。

「OAuth 2.0 實戰」有一章決策圖可以幫助你決定使用什麼模式。但本系列應該不會提供。

  • ««
  • «
  • 1
  • 2
  • 3
  •  … 
  • 9
  • 10
  • 11
  •  … 
  • 34
  • »
  • »»
© 又LAG隨性筆記 2025