标签为“用Keycloak學習身份驗證與授權”的页面如下
【用Keycloak學習身份驗證與授權】系列目錄
本系列同樣發表於iThome體人賽 - 用Keycloak學習身份驗證與授權。
本頁後面還有一些小後記喔~
- 【用Keycloak學習身份驗證與授權01】Quick Start(1)
- 【用Keycloak學習身份驗證與授權02】Quick Start(2)
- 【用Keycloak學習身份驗證與授權03】淺談身份驗證與授權(1)
- 【用Keycloak學習身份驗證與授權04】淺談身份驗證與授權(2)
- 【用Keycloak學習身份驗證與授權05】什麼是Keycloak
- 【用Keycloak學習身份驗證與授權06】Keycloak的替代品
- 【用Keycloak學習身份驗證與授權07】什麼是OAuth
- 【用Keycloak學習身份驗證與授權08】OAuth 2
- 【用Keycloak學習身份驗證與授權09】再談身份驗證與授權
- 【用Keycloak學習身份驗證與授權10】深入OAuth 2
【用Keycloak學習身份驗證與授權33】Device Code(4)
這次應用使用PySide
來實現界面;qrcode
來產生需要的QR Code;並使用requests
來與身份驗證與授權伺服器的API溝通。現在透過pip
進行安裝需要的packages。
pip install PySide6 requests qrcode
其實本來可以考慮用electron.js,但是基於一些考量,最後決定使用PySide。
在昨天,透過Qt Designer建立了兩個需要的使用者界面,今天來實現邏輯部分。
建立Widget
在之前所設計的ui檔案分別是:example-device-code-app.ui
和login-dialog.ui
。這部分會分別將這兩份載入到類別內使用。所以同樣來建立兩個Widgets:ExampleDeviceCodeApp
和loginDialog
。
【用Keycloak學習身份驗證與授權32】Device Code(3)
本文接續device code(2)
現在已經知道了Device Code的登入流程了,那麼實際應用起來是怎麼樣的呢? 本片來實現一個可以使用Device Code Flow登入的應用。
使用者界面設計
首先,與「快速開始」應用相同,同樣需要一個顯式使用者資訊的地方,以及登入與登出的按鈕。
是的非常簡單。但悄悄先回到RCF8628,有一部分描述使用者界面的範本。該界面建議包含:操作說明、登入連接和user_code
。
【用Keycloak學習身份驗證與授權31】Open ID Connect & Social Login(2)
Keycloak Open-Id Connect
其實除了使用GitHub等社群帳號登入外,Keycloak也可以作爲Open-Id登入的提供者(Provider)。接著需要使用Keycloak本身來實現社群帳號登入,因爲這樣子可以看到更多細節。
建立新的Realm
現在,需要一個新的帳號系統。你可以在建立一個Keycloak伺服器,或是建立一個新的Realm。不同Realm的帳號系統是獨立不相干擾的,所以這裏就先建議一個新的Realm – G00gle
。
【用Keycloak學習身份驗證與授權30】Open ID Connect & Social Login(1)
因為略過了一些JWT格式細節分析。所以這部分也有部分不會好好提到
到目前爲止,爲何不同應用可以使用同一個帳號登入,已經在說明Client解釋過。這是在相關系統的應用下,那麼…沒直接相關的系統呢?譬如:使用Google登入。像這種使用不同帳號系統登入的方式,在Keycloak分成兩種。第三方系統登入,這篇僅會說明與 OAuth / Open-Id 相關的一種。如果你使用過Firebase、Auth0等服務,或是看過使用Google、Facebook、Microsoft、GitHub帳號登入的應用,對就是這類。這種社群帳號登入(Social Login)的方式,與前幾天提到的內容相關,而且可以在Keycloak實現。
鐵人賽只會實現而已,一些細節和更多的範例並不會提到。 (雖然原本就計劃寫)
Social Login 社群帳號登入
以GitHub帳號登入
【用Keycloak學習身份驗證與授權29】JWT權杖格式介紹(1)
總覺得…直接開始說明什麼是JWT格式來著。但感覺這樣會很無聊,不如我們從已經拿到的Token來看吧!
至今爲止,除了存取權杖(access_token
)、更新權杖(refresh_token
)外,還拿到過識別權杖(id_token
)。仔細看三者,都有兩個「.
」可以將權杖分成三個部份。
這些權杖都可以透過JWT.io去解析。總之先透過Password Grant Flow取得access_token
和refresh_token
,或是透過「快速開始」應用取得id_token
。
【用Keycloak學習身份驗證與授權28】Role
在帳號系統下,除了帳號本身與帳號群組外,通常還存在一個非常重要的部分–角色(Role),更有基於角色的存取授權方式(RBAC)。
寫到有點累了,沒意外的話之後是會提到RBAC
帳號如果代表一個人,這個人可能有多個角色身份。可能是個老師、主任、校長;可能是爸媽、叔姨;可能是員工、部長、處長、老闆,且可能有一群人擁有同一種角色。角色和帳號群組有點像,但在Keycloak是兩個概念。除此之外,在Keycloak還分成兩類型角色– Realm Roles 和 Client Roles 。
建立 Realm Roles
首先,你可以建立Realm共用的角色,像是員工、老闆等等較爲通用的角色。
點選在 Realm 選單下的 Roles ,然後再點選 Add Role :
【用Keycloak學習身份驗證與授權27】User & Claim & Profile
接著來看看爲什麼更新帳號資訊,在「快速開始」會有那些變化。
這與client scope和claim有關。關於後者之後會在詳細說說,而目前就先了解一下這個現象發生的原因。
首先,在我們取得token
的時候曾申明需要的scope
爲openid profile email
。其中profile
這個scope爲這次變化的主要原因。
來到Keycloak管理選單下的 Client Scopes ,然後找到 profile 。
接著將頁籤切換到 Mappers , 你會看見一堆與 User Attribute 有關的設定。
【用Keycloak學習身份驗證與授權26】User & Group
帳號(User)
基本訊息
接著來看看與帳號有關的設定。
在之前,已經建立過一帳號–bob
。過去學習實驗,也都以bob驗證身份。接著我們要來更新一下這個帳號。
首先看一下基本訊息:
來添加一些資訊:
- Email:
bob@fake.email
- First Name:
Bob
- Last Name:
Lee
- Email Verified:
ON
此外,可以要求使用者在必須做一些事情,譬如:驗證信箱、更新密碼、更新個人資訊等。
再次登入到應用–「快速開始」,可以看到有一些訊息也有些不同了。
【用Keycloak學習身份驗證與授權24】Clients
Client與一些安全相關的設定
在OAuth架構下的Client(客戶端)可以想象成是一個一個的應用程式。到目前爲止也已經建立過幾個Client:
這些Client有著自己的規則、資源、授權方式等。
可以複寫一些Realm的設定,包含產生存取權杖的方式。像是認爲RS256
簽名不夠,需要使用到RS512
:
【用Keycloak學習身份驗證與授權23】Realm
Realm,中文或許會翻作「域」,但基本很像是程式開發上,語言層面提供的包(package
)或是命名空間(namespace
)。或者可能可以更貼切的說是工作空間(workspace)。
你可以想象就像是一個企業、部門或是其他組織。有著相同的一些規範,同事們在同樣地工作空間生活、工作。但不同的企業、部門或是其他組織,可能會有類似的規範,但兩者不互相影響。
會特別有這個概念,是因爲Keycloak是可以建立多個Realm的。也就是,在同一間公司內,不同部門都可以有自己的Realm,制定部門自己的管理規範。或是特別爲外部客戶建立一個Realm,並制定特殊規範。
不同的Realm內,有著自己的帳號系統、密碼規範政策等。利用這個特性,之後也會用來更清楚的理解Open-Id。
你也可以同樣簡單視爲一個帳號資料庫、身份驗證伺服器。特別的是在會話成立期間,可以不需要再進行一次驗證,而這部分,會在提到Client時在多做說明。
如何建立一個Realm
要建立一個Realm是非常簡單。在之前也建立過「quick-start」這個Realm。也幾乎就只需要給個名字而已。
【用Keycloak學習身份驗證與授權22】Keycloak使用基本概念:前導
【用Keycloak學習身份驗證與授權21】在Flow這段小旅途外的風景
在這一小段路中介紹了Password Flow、Implicit Flow、Code Flow、Refresh Token Flow、Client Credentials Flow、PKCE、Device Code Flow。有些模式已經被發現可能有潛在風險,有些模式無法單獨使用。這或許還不是全部,至少到現在為止都還沒有提到過金融級應用Flow–CIBA。
Client Initiated Backchannel Authentication Profile(CIBA)
本小節也不會詳細介紹CIBA(Client Initiated Backchannel Authentication)。儘管CIBA現在階段還只是草案(Draft),但在Keycloak v15版本中已經可以使用。大概也已經確實有一些應用使用。
為什麼你不該繼續使用Implicit Flow?
在談到Implicit Flow時候,提到過:
將存取權杖暴露在使用者面前也不是非常好的做法
【用Keycloak學習身份驗證與授權20】Device Code(2)
光要完成這個範例就花了幾乎整整一天
做完後決定…來拆篇這第二部份,將有部份內容會在【實戰篇】展開。 今天就先來看看成果。
成果發表
【用Keycloak學習身份驗證與授權19】Device Code(1)
+----------+ +----------------+
| |>---(A)-- Client Identifier --->| |
| | | |
| |<---(B)-- Device Code, ---<| |
| | User Code, | |
| Device | & Verification URI | |
| Client | | |
| | [polling] | |
| |>---(E)-- Device Code --->| |
| | & Client Identifier | |
| | | Authorization |
| |<---(F)-- Access Token ---<| Server |
+----------+ (& Optional Refresh Token) | |
v | |
: | |
(C) User Code & Verification URI | |
: | |
v | |
+----------+ | |
| End User | | |
| at |<---(D)-- End user reviews --->| |
| Browser | authorization request | |
+----------+ +----------------+
Figure 1: Device Authorization Flow
The device authorization flow illustrated in Figure 1 includes the
following steps:
(A) The client requests access from the authorization server and
includes its client identifier in the request.
(B) The authorization server issues a device code and an end-user
code and provides the end-user verification URI.
(C) The client instructs the end user to use a user agent on another
device and visit the provided end-user verification URI. The
client provides the user with the end-user code to enter in
order to review the authorization request.
Device Code Flow這個與前面幾個特別不一樣。在之前,以往都是從登入開始,然後跳轉頁面回到App(Client)。也就是通常先有的是前端通訊,然後才是後端通信。
【用Keycloak學習身份驗證與授權18】PKCE
+-------------------+
| Authz Server |
+--------+ | +---------------+ |
| |--(A)- Authorization Request ---->| | |
| | + t(code_verifier), t_m | | Authorization | |
| | | | Endpoint | |
| |<-(B)---- Authorization Code -----| | |
| | | +---------------+ |
| Client | | |
| | | +---------------+ |
| |--(C)-- Access Token Request ---->| | |
| | + code_verifier | | Token | |
| | | | Endpoint | |
| |<-(D)------ Access Token ---------| | |
+--------+ | +---------------+ |
+-------------------+
Figure 2: Abstract Protocol Flow
PKCE模式
說穿了PKCE是基於Code flow的安全強化版。在整個過程前後添加了兩個動作–產生code_verifier
和code_challenge
,並在最後透過code_challenge
驗證code_verifier
。其目的有很大程度是為了建立前端通訊與後端通訊的關聯。
原先風險
那麼先來看看原本發生了什麼問題。
【用Keycloak學習身份驗證與授權17】Client Credentials
+---------+ +---------------+
| | | |
| |>--(A)- Client Authentication --->| Authorization |
| Client | | Server |
| |<--(B)---- Access Token ---------<| |
| | | |
+---------+ +---------------+
Figure 6: Client Credentials Flow
嘗試 Client Credentials flow
Client Credentials,這個模式有點特別。除了前面看到的它可能與其他模式並用以外,最特別的是,單純使用它,完全不需要資源擁有者參予。總之先來看看:
你可以使用RESTfer嘗試看看:
grant_type: client_credentials
client_id: oauth_tools
client_secret: <之前所產生的secret>
或是同樣可以透過OAuth.Tools嘗試看看。
【用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
。
【用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))。
【用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)」也就不會太難理解。
【用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
【用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本身的部分。
【用Keycloak學習身份驗證與授權11】OAuth 2
終於要來談談OAuth裡定義的細節了~
目前OAuth 2.0 一共定義了7種流程(flow)。在未來本系列可能稱之爲模式,不同模式適用於不同情況、不同環境。 就是因爲如此,OAuth才有高彈性的優勢。
OAuth 2.0 的可擴展性和模塊化是其最大的優勢之一,因為這使得該協議適用於各種環境。然而,正是這種靈活性導致不同的實現之間存在基本的相容性問題。當開發人員想在不同的系統上實現 OAuth 時,它提供的眾多自定義選項容易使人困惑。
本系列會介紹的模式包含:
- Password Grant (密碼模式)
- Implicit (隱含模式)
- Authorization Code (Code模式)
- Refresh Token
- Client Credentials (特殊密碼模式)
- PKCE
- Device Code
儘管 Implicit 和 Password Grant 被標記爲傳奇的(Legacy),但有時候仍然可能會使用到。重要的是你應該知道什麼情況應該使用什麼模式。同時記住,即使一個系統按照規範正確地實現了 OAuth,也不意味著該系統在實踐中就是安全的。
「OAuth 2.0 實戰」有一章決策圖可以幫助你決定使用什麼模式。但本系列應該不會提供。
【用Keycloak學習身份驗證與授權10】深入OAuth 2
喔不,其實今天還不會真正提到OAuth 2.0的深度內容。今天要來談談的是取得資源的細節。
使用帳號密碼,假裝自己是用戶
首先先試著想想看,如果你想要寫一支程式代替你處理某些事情。譬如:收信、發信。 更詳細的說,你寫了一個信件的客戶端(如:Thunderbird、Outlook)。 然後你會需要告訴這支程式你信箱的登入帳號密碼,由他去代替你收信、寄信。這個樣子就像是你把你所有的祕密都交給了它, 交給了它那把萬能鑰匙,而你完全信任這支程式。
其實這種狀況還真不少見。尤其在於你所申請的帳號,和使用的客戶端服務實際就是同一個時,這種行爲在正常不過。
但當它們是不同服務時,就可能出現問題了。你還能信任你提交的密碼不會被誤用嗎?不可能發生?
你可能有Gmail的帳號,你會很正常的使用Gmail的服務。但你知道Gmail除了自己本身外,它還可以幫你收其他信箱嗎?
比如說你還有ymail的帳號,但你更喜歡Gmail的界面,所以你希望使用Gmail來處理yamil的信件。這時候其實你就是告訴了Gmail 關於yamil的帳號密碼。相對的,也就是你應該是信任的Google的服務。
【用Keycloak學習身份驗證與授權09】再談身份驗證與授權
再談身份驗證與授權
現在,讓我們再一次把視線放到「身份驗證」和「存取控制」這些名詞身上。 在入門篇的「淺談身份驗證與授權」已經相當程度的解釋過各個名詞。 不過今天將要更關注在身份驗證與存取控制的細節上。
對於一個應用來說,最重要的是它的 業務邏輯 。 除了業務邏輯本身,為完成所需的工作,會需要取得必要之資源。這可能是一份檔案, 鏡頭、麥克風資源等不同種形式。
在 取得資源 過程中,也會有另外一層業務邏輯,也可能本身就是另一隻程式服務,對所需取得的資源,進行 存取控制 。
最後,爲了判斷是否具有存取該項資源的權限,有可能有必要進行 身份驗證或授權 。
【用Keycloak學習身份驗證與授權08】OAuth 2
這是入門篇的最後一天了,今天不會寫什麼內容,但來帶大家看個入門概念可用的工具 – OAuth 2.0 Playground。
OAuth 2.0定義了幾個flow,可用於不同情境下,由於後續會有更多詳細說明,所以今天只會帶大家初步認識,嚐鮮看看。
註冊帳號
點選 register a client and a user。別擔心,這是個隨時可以廢棄的帳號。你完全不用真的去記他,他也不會要求你提供什麼資訊。
然後你會得到一組帳號密碼。然後點選「open in new window」之後就可以按下「continue」。
【用Keycloak學習身份驗證與授權07】什麼是OAuth
先來回憶一下,何爲「授權」。試想像有一座宅邸,裏頭有無數房間。而你作爲這座宅邸的管家,擁有一把萬能鑰匙,可以開始宅邸內所有門扉。 此外,這把萬能鑰匙還有一個作用,就是產生出開啓特定門扉的鑰匙。 你可以產生出的鑰匙交給其他人,其他人就可以自由進出特定房間。這個動作就是「授權」。
OAuth 是一個開放標準的 授權協議 ,它允許 軟體應用 代表 資源擁有者 訪問資源擁有者的 資源 1。
OAuth是什麼?
【用Keycloak學習身份驗證與授權05】什麼是Keycloak
終於要來好好介紹一下甚麼是Keycloak了~
收先先來看一下Keycloak的基本資訊:
- 名稱: Keycloak
- 開發使用的程式語言: Java
- 公用: 單點登入驗證與授權工具
- 許可協議: Apache License 2.0
- 公開倉庫: https://github.com/keycloak/keycloak
- 官方網站: https://www.keycloak.org
- 撰寫當下最新版本: 15.0.2 (2021年8月20日)
在 快速開始 提到過起始畫面有一些細節:
【用Keycloak學習身份驗證與授權04】淺談身份驗證與授權(2)
實際上,在昨天已經將多數基礎都已經解釋過了,不過我想到還有一些東西可以再多做補充的。
對啦! 擔心彈藥不足,把一篇拆成兩篇來啦!👻
沒有身份識別的存取控制
在我們拆分的整個流程中分成:身份識別、身份驗證、授權、存取控制。但現在,你將Web App登出後再登入一次,你會發現「授權」的部分不見了! 但我們不會立刻來討論這個部分。先來說說身份識別。
不覺得,身份識別在整個流程之中非常雞肋嗎?也就只是將你這個「自然人」與系統中存在的「帳號」對應起來。 也確實如此,在這樣的拆分中,身份識別對於存取控制並不是必要的。在後來已MAC爲基礎發展的存取控制框架,也多不直接與帳號相關。
別擔心,之後會提到什麼是MAC(強制存取控制, Mandatory Access Control)。
不過還有一個更直接沒了這個流程的例子。在以「單人使用」作爲設計的系統之中,我們只需要拿到鑰匙就可以進行存取。
什麼?你說現在還有這種系統嗎?其實還真不少呢,加密上鎖過的壓縮檔案,上鎖的部落格文章。還有授權之後的流程,可能也不包含身份識別。
【用Keycloak學習身份驗證與授權03】淺談身份驗證與授權(1)
在「快速開始」的單元中,實際上已經完成了所有身份識別、身份驗證、授權和一些存取控制的流程。
在今天,將會來說說,這些看是相同,卻又有一些不同的名詞。
名詞認識
那麼首先,就先來認識各個名詞的英文吧!
名詞 | 英文 | 簡短說明 |
---|---|---|
身份識別 | Identification | 讓系統知道你是誰 |
身份驗證 | Authentication | 讓系統相信你是誰 |
授權 | Authorization | 允許他人存取某項資源 |
存取控制 | Access Control | 檢驗是否有資格存取某項資源 |
而我認爲軟體開發上,最重要的是 存取控制 。這直接關係到系統上的資源,但卻無法只存在存取控制,勢必需要身份驗證與授權的配合。這也是爲什麼我們很難將這些分開來看。
已「快速開始」爲例
現在,讓我們把視線重新放回剛弄好的「快速開始」。在這個範例中,已經多少碰觸到了每一塊的概念。首先是身份識別:
【用Keycloak學習身份驗證與授權02】Quick Start(2)
昨天,已經完成了一部分配置,且也已經可以建立帳號並登入了。
不過,這只能算是半套,而今天要在來完成另外半套。
你可以按照昨天的做法,重新建立一個新的Client。
只是注意在建立的時候,「Root URL」改爲: http://localhost:4200
。
今天,我們要自己實現一個前端網頁去的Web App,然後綁定Keycloak去做登入。
前置要求:
- 用Keycloak建立一個Client
- 網頁開發基礎知識(HTML/CSS/JavaScript)
- TypeScript的部分知識
- Angular知識(非必要)
調整Keycloak的Client配置
前面說過,Keycloak的Client實際上並不是真正的Client Application,只是做了一些關聯。 今天就要來 快速開始 個自己的Web App。而首先,需要先調整Client的關聯:
- 選擇「Clients」
- 找到昨天建立的「my-quick-start-app」,然後點選「Edit」
這此調整主要做兩個修改:
【用Keycloak學習身份驗證與授權01】Quick Start(1)
開始之前~2🎃。開完笑的~
但是想了許久,總覺的就這麼直接開始解釋各個名詞不太好。
想找個範例又有諸多擔心。
不如…先來快速開始做個範例!
快速開始將分成兩天。 今天會先跑過一次簡單的流程,明天才會寫一點程式。
這兩天看完後,依照需求,你甚至可以開始開發自己的應用。
那我們從Keycloak開始吧!
今天的前置需求:
- 只要裝好docker就好囉~
- 阿!對,你還要安裝個瀏覽器。
(不過你拿什麼在看本系列文章呢?)
透過Docker建立一個Keycloak應用
docker run -p 8080:8080 -e KEYCLOAK_USER=admin -e KEYCLOAK_PASSWORD=admin quay.io/keycloak/keycloak:15.0.2
這麼一條指令就可以開始這系列多數內容了(吧)。現在Keycloak會聆聽本機的8080 port。嘗試用瀏覽器開啓 http://localhost:8080 後,你應該會看到以下畫面:
【用Keycloak學習身份驗證與授權00】開始之前
這系列文章將帶大家探討軟體開發上,那些身份驗證與授權的相關議題。此外的話題還有身份識別、存取控制。 以目前諸多流行應用都以非單人使用的狀況之下,身份驗證與授權,幾乎是每位開發者都會遇到的題目。 不管你是串接OAuth、管理資源、寫後臺界面,甚至在最初應用的設計,幾乎都會扯上邊。 在業務邏輯之外,這或許會是相當重要的一部分。
關於身份驗證與授權,每一個部分都非常重要,也都可以分開來看,卻也非常難分開來看。
Because these three techniques are so closely related in most real applications, it is difficult to talk about them separate from one another. In particular, authentication and authorization are, in most actual implementations, inextricable. 1
就如同在Oracle上可查詢到的相關資料,這些部分儘管代表者不同概念,但彼此非常相關,實在很難分開來看。雖然如此,每一個部分都是非常龐大的內容,而本系列將會着重於授權控制與存取控制。在此之上會在探討近來已經非常普遍的OAuth 2.0、Open-Id、單點登入(SSO)和基於角色的存取控制(RBAC)