iT邦幫忙

2021 iThome 鐵人賽

DAY 9
1
Software Development

用Keycloak學習身份驗證與授權系列 第 9

Day08 - 【入門篇】OAuth 2.0 Playground

本系列文之後也會置於個人網站


這是入門篇的最後一天了,今天不會寫什麼內容,但來帶大家看個入門概念可用的工具 -- OAuth 2.0 Playground

OAuth 2.0定義了幾個flow,可用於不同情境下,由於後續會有更多詳細說明,所以今天只會帶大家初步認識,嚐鮮看看。

註冊帳號

點選 register a client and a user。別擔心,這是個隨時可以廢棄的帳號。你完全不用真的去記他,他也不會要求你提供什麼資訊。

然後你會得到一組帳號密碼。然後點選「open in new window」之後就可以按下「continue」。

在另外一個視窗中會有相同帳號密碼的資訊。如果你的系統允許視窗置頂,我會建議你先將其置頂。

Implicit 隱含模式

首先,先試試其實已經用過的隱含模式。

你可以先不理解這部分內容,直接點選「Authorize」

然後輸入你剛剛註冊得到的帳號密碼登入:

允許授權

同樣先不用理解什麼是state,直接選擇「It Matches, Continue!」

現在就拿到存取權杖(Access Token)了,並且這個權杖擁有的權限範圍(scope)是photo

儘管我們之後會將permission和scope概念分開,但你可以先理解成同樣東西。

Authorization Code

接著來試試所有裡面最爲標準,最爲基礎的code模式。

同樣先不用理解

然後登入

授權

It Matches, Continue!

And then 「Go」

然後就拿到權杖(token)了。

What!? 怎麼好像沒什麼差別?

這就對了。在使用者登入使用應用的情況,會更難察覺其中差異。

在一般情況下,OAuth協議是不會被用戶察覺到的,例如Steam和Spofity的桌面應用。除非主動的去探尋OAuth的痕跡,否則用戶永遠部會知道他使用了OAuth。這是很好的特性,因為優秀的安全系統在一切功能都正常時就應咳不被察覺。
-- OAuth 2.0 實戰

同樣地 OpenID Connect 也非常相似,儘管它目的性有點不同,但就不再多演示了。

PKCE

PKCE和Code模式很像,只是再一開始和最後有點不同,它是更安全的授權方式。讓我們來看看吧!

先產生爲安全需要的資訊:

然後就和code模式有點像了

登入

授權

It Matches, Continue!

取得權杖(Token)

然後是差不多的結果


在這個Playground的Device Code模式我認爲意義不大,之後會帶大家透夠其他方式來看看。

那麼今天的內容也就到此爲止了。恭喜各位看完入門篇的所有內容,接下來的內容是會蠻燒腦的概念篇和實戰篇了。


上一篇
Day07 - 【入門篇】什麼是OAuth
下一篇
Day09 - 【概念篇】再談身份驗證與授權
系列文
用Keycloak學習身份驗證與授權41
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言