Identity Server 4 預備知識 -- OpenID Connect 簡介

原文: Identity Server 4 預備知識 -- OpenID Connect 簡介

我以前的文章簡單的介紹了OAuth 2.0 (在這裏: http://www.javashuo.com/article/p-gtjytgin-ch.html), 還不是很全.

這篇文章我要介紹一下 OpenID Connect.

OAuth 2.0 不是身份認證協議

OAuth 2.0 不是身份認證(Authentication)協議. 爲何有人會認爲OAuth 2.0具備身份認證的功能? 這是由於OAuth2常常做爲身份認證(Authentication)協議的一部分來使用. 例如在典型的OAuth2流程裏, OAuth2常常會嵌入一些身份認證的事件.

那麼身份認證(Authentication)是什麼?

咱們這裏所說的身份認證就是指它能夠告訴應用程序當前的用戶是誰, 還有這些用戶是否正在使用你的應用程序. 它是一種安全架構, 它能夠告訴你用戶是他們所聲明的身份, 一般呢, 是經過提供一套安全憑據(例如用戶名和密碼)給應用程序來證實這一點.

而OAuth2則無論用戶這些東西, OAuth2的客戶端應用只考慮請求token, 獲得token, 使用token訪問API. 它不關心誰給客戶端應用受權了, 也不關心是否有最終用戶.\

 

身份認證(Authentication) vs 受權(Authorization)

引用《OAuth 2.0 in Action》裏面的一個比喻來解釋, 把身份認證看做是軟糖, 而受權是巧克力. 這兩種東西感受略有類似, 可是本質上卻大相徑庭: 巧克力是一種原料, 而軟糖是一種糖果. 可使用巧克力做爲主要原料作出巧克力口味的糖果, 可是巧克力和軟糖毫不是等價的.

儘管巧克力能夠單獨做爲一種最終產品, 但在這個比喻裏巧克力是一種很是有用原料, 它極具多樣性, 能夠用來作蛋糕, 冰激凌, 雪糕等等.

 

在這個比喻裏 OAuth 2.0 就是巧克力, 它是衆多web安全架構的一種多用途的基本成分.

而軟糖, 是一種糖果. 有一種特別可口的軟糖叫作巧克力軟糖. 很顯然, 巧克力在這種軟糖裏是主要成分, 可是它還須要其它原料成分和一些關鍵的流程把巧克力轉化成巧克力軟糖.

製作出的產品是軟糖的形式, 它以巧克力爲主要成分. 這叫使用巧克力來製做軟糖, 因此說巧克力不等價於軟糖.

在這個比喻裏, 身份認證就更像軟糖, 它須要一些關鍵的組件和流程, 而卻要把這些組件和流程經過正確的組合起來並安全的使用, 針對這些組件和流程仍是有不少的選項的.

能夠說咱們要製做巧克力軟糖, 也就是須要一個基於OAuth2的身份認證協議. 而OpenID Connect就是這樣的開放標準, 它能夠工做於不一樣的身份供應商之間. OpenID Connect 基於 OAuth 2.0, 在此之上, 它添加了一些組件來提供身份認證的能力.

 

OpenID Connect的官方定義是: OpenID Connect是創建在OAuth 2.0協議上的一個簡單的身份標識層, OpenID Connect 兼容 OAuth 2.0. 

 

OAuth 2.0與身份認證協議的角色映射

想要基於OAuth2構建身份認證協議, 那麼就須要把OAuth2裏面的那些角色映射到身份認證的事務裏面.

在OAuth2裏面, 資源全部者(Resource Owner)和客戶端應用(Client)常常在一塊兒工做, 由於客戶端應用表明了資源全部者. 而受權服務器(Authorization Server)和被保護的資源(Protected Resource)常常在一塊兒, 由於受權服務器生成token, 而被保護的資源接收token. 因此說在最終用戶/客戶端應用 與 受權服務器/被保護資源 以前存在一個安全和信任的邊界, 而OAuth2就是用來跨越這個邊界的協議.

而在身份認證的事務裏, 最終用戶使用身份提供商(Identity Provider, IdP)登陸到依賴方(Relying Party, RP, 能夠理解爲客戶端).

總結一下前面這段話:

OAuth2裏能夠分爲兩部分: 1.資源全部者/客戶端應用, 2.受權服務器/被保護資源.

身份認證協議裏也是兩大部分: 1.依賴方, 2.身份提供商.

因此考慮這樣映射:

• OAuth2裏的受權服務器/被保護資源 ---- 身份認證協議裏的身份提供商進行映射
• OAuth2裏面的資源全部者 ---- 身份認證協議裏的最終用戶
• OAuth2的客戶端應用 ---- 身份認證協議裏的依賴方(RP).

OAuth2裏, 資源全部者的權限會委派給客戶端應用, 但這時該權限對應的被保護資源就是他們本身的身份信息. 也就是說他們受權給依賴方(RP), 讓其能夠知道如今是誰在使用應用, 而這就是身份認證事務本質.

依賴方如今就能夠知道是誰在使用系統而且他們是如何登陸進來的. 不過這裏還須要用到另一種token, 叫作ID token, 這種token攜帶着身份認證事件自己的信息.

那麼爲何不使用OAuth2裏的access token把這些事都一次性解決了呢? 

由於首先access token不含有任何關於身份認證的信息; 其次access token的生命期可能會很是的長, 即便用戶離開了它仍有可能有效, 它還有可能被用於無最終用戶參與的狀況; 還有一種狀況就是access token可能會被其它的客戶端應用借用. 因此, 不管客戶端是如何獲得的access token, 它都沒法從access token裏獲得最終用戶的信息以及最終用戶的身份認證狀態.

在OAuth2裏, access token不是爲客戶端準備的, 它對於客戶端應該是不透明的, 可是客戶端也須要從access token獲得一些用戶信息. 實際上客戶端應用只是access token的展現者, access token真正的目標觀衆是被保護的資源.

在OpenID Connect裏, 這個第二個叫作ID Token, 它會和access token一同發送給客戶端應用.

 

OpenID Connect

OpenID Connect是由OpenID基金會於2014年發佈的一個開放標準, 簡單的說就是, 它使用OAuth2來進行身份認證. OpenID Connect直接構建於OAuth2.0的基礎之上, 與其兼容. 一般OpenID Connect是和OAuth2一同部署來使用的.

 

OpenID Connect的總體抽象流程以下圖所示: 

1. 依賴發(RP)發送請求到OpenID提供商(OP, 也就是身份提供商).

2. OpenID提供商驗證最終用戶的身份, 並得到了用戶委派的受權

3. OpenID提供商返回響應, 裏面帶着ID Token, 也一般帶着Access Token.

4. 依賴方如今可使用Access Token發送請求到用戶信息的端點.

5. 用戶信息端點返回用戶的聲明(claims, 至關因而用戶的信息).

 

OpenID Connect的ID Token 和用戶信息端點之後在使用Identity Server 4的時候在進行介紹.

 

身份認證

OpenID Connect 會負責身份認證這個動做, 也就是把最終用戶登陸到系統, 或者判斷最終用戶是否已經登陸了. OpenID Connect會經過一種安全的方式從服務器把身份認證的結果返回給客戶端, 這樣客戶端就能夠依賴於它了. 也是由於這個緣由, 客戶端被稱爲了依賴方(RP). 這個身份認證的結果就是ID Token.

OpenID Connect身份認證有三個路徑(三個流程, flow): Authorization Code 流程, Implicit 流程, Hybrid 流程.

 

Authorization Code Flow

在Authorization Code 流程裏, 一個受權碼(Authorization Code)會被返回給客戶端. 這個受權碼能夠被直接用來交換ID Token和Access Token. 該流程也能夠在客戶端使用受權碼兌換Access Token以前對其身份認證. 可是該流程要求客戶端的身份認證動做在後臺使用client id和secret來得到tokens, 這樣就不會把tokens暴露給瀏覽器或其它可訪問瀏覽器的惡意應用了.

這種流程要求客戶端應用能夠安全的在它和受權服務器之間維護客戶端的secret, 也就是說只適合這樣的客戶端應用.

它還適合於長時間的訪問(經過refresh token).

Authorization Code流程的受權碼來自於受權端點, 而全部的tokens都來自於Token端點. 

Authorization Code流程的步驟以下:

1. 客戶端準備身份認證請求, 請求裏包含所需的參數
2. 客戶端發送請求到受權服務器
3. 受權服務器對最終用戶進行身份認證
4. 受權服務器得到最終用戶的贊成/受權
5. 受權服務器把最終用戶發送回客戶端, 同時帶着受權碼
6. 客戶端使用受權碼向Token端點請求一個響應
7. 客戶端接收到響應, 響應的body裏面包含着ID Token 和 Access Token
8. 客戶端驗證ID Token, 並得到用戶的一些身份信息.

 

Implicit Flow

Implicit流程在請求token的時候不須要明確的客戶端身份認證, 它使用重定向URI的方式來驗證客戶端的身份. 由於這一點, refresh token也就沒法使用了, 這一樣也不適合於長時間有效的access token.

在Implicit流程裏, 全部的tokens都來自於受權端點, 而Token端點並無用到.

該流程主要用於瀏覽器內的應用, Access Token和ID Token一同被直接返回給客戶端. 由於這個緣由, 這些tokens也會暴露於最終用戶和能夠訪問該瀏覽器的其它應用了. 

它並不適合於長時間的訪問.

Implicit流程的步驟以下:

1. 客戶端準備身份認證請求, 請求裏包含所需的參數
2. 客戶端發送請求到受權服務器
3. 受權服務器對最終用戶進行身份認證
4. 受權服務器得到最終用戶的贊成/受權
5. 受權服務器把最終用戶發送回客戶端, 同時帶着ID Token. 若是也請求了Access Token的話, 那麼Access Token也會一同返回.
6. 客戶端驗證ID Token, 並得到用戶的一些身份信息.

 

Hybrid Flow

Hybrid流程是前二者的混合, 在該流程裏, 有一些tokens和受權碼來自於受權端點, 而另一些tokens則來自於Token端點.

該流程容許客戶端當即使用ID Token, 而且只須要一次往返便可得到受權碼.

這種流程也要求客戶端應用能夠安全的維護secret.

它也適合於長時間的訪問.

Hybrid流程的步驟以下:

1. 客戶端準備身份認證請求, 請求裏包含所需的參數
2. 客戶端發送請求到受權服務器
3. 受權服務器對最終用戶進行身份認證
4. 受權服務器得到最終用戶的贊成/受權
5. 受權服務器把最終用戶發送回客戶端, 同時帶着受權碼, 根據響應類型的不一樣, 也可能還帶着一個或者多個其它的參數.
6. 客戶端使用受權碼向Token端點請求一個響應
7. 客戶端接收到響應, 響應的body裏面包含着ID Token 和 Access Token
8. 客戶端驗證ID Token, 並得到用戶的一些身份信息.

 

三種流程特色的比較:

	Authorization Code Flow	Implicit Flow	Hybrid Flow
全部的tokens都來自於受權端點	no	yes	no
全部的tokens都來自於Token端點	yes	no	no
Tokens對瀏覽器隱藏	yes	no	no
客戶端能夠被認證	yes	no	yes
可使用Refresh Token	yes	no	yes
只需一次往返通訊	no	yes	no
大部分通訊都是服務器對服務器	yes	no	看狀況

 

返回類型值的比較: 

"response_type" 的值	Flow
code	Authorization Code Flow
id_token	Implicit Flow
id_token token	Implicit Flow
code id_token	Hybrid Flow
code token	Hybrid Flow
code id_token token	Hybrid Flow

 

本文就簡單介紹這些, OAuth 2.0 和 OpenID Connect 其他涉及到的內容會在後續Identity Server 4的系列文章裏介紹.