Introduction

OAuth2是一個授權(quán)框架,， 可以使一個應(yīng)用程序獲取其他HTTP服務(wù),， 比如Facebook, 的用戶賬號的部分權(quán)限,。 當(dāng)一個第三方應(yīng)用程序想要訪問用戶賬號時， OAuth2會把驗證的過程委托給含有用戶賬號信息的應(yīng)用程序,。OAuth2提供了Web, Desktop applications, mobile devices的授權(quán)流,。
?

OAuth Roles

OAuth定義了四種角色：

• Resource Owner
• Client
• Resource Server
• Authorization Server

Resource Owner(資源擁有者):User
資源擁有者， 即授權(quán)應(yīng)用程序訪問他們賬號的用戶,。 應(yīng)用程序?qū)τ脩糍~號的權(quán)限為授權(quán)后的token中scope字段指定的范圍,。

Resource / Authorization Server(資源提供者/授權(quán)服務(wù)器): API
資源提供者提供被保護(hù)的用戶賬號的信息， 授權(quán)服務(wù)器驗證用戶(資源擁有者)的身份信息,， 然后簽發(fā)access token給應(yīng)用程序,。

Client（客戶端）: Application
Client即想要訪問用戶賬號的應(yīng)用程序。 在應(yīng)用程序訪問用戶賬號之前,， 必須獲得用戶的授權(quán),。
?

Abstract Protocol Flow

1. 應(yīng)用程序請求用戶授權(quán)訪問被保護(hù)的用戶資源。
2. 如果用戶授權(quán)應(yīng)用程序,， 則應(yīng)用程序會獲得一個授權(quán)。
3. 應(yīng)用程序向授權(quán)服務(wù)器(authorization server)表明自己的身份以及用戶的授權(quán)并請求access token,。
4. 如果應(yīng)用程序的身份驗證通過并且用戶的授權(quán)有效,， 則授權(quán)服務(wù)器(authorization server)會簽發(fā)一個access token給應(yīng)用程序,， 授權(quán)完成。
5. 應(yīng)用程序向資源服務(wù)器(resource server)發(fā)起請求并展示access token,。
6. 如果access token有效,， resource server會提供被保護(hù)的資源給應(yīng)用程序。

在使用OAuth之前,， 必須向Authorization Server注冊應(yīng)用程序(application),， 注冊時需要提供Application name, Application Website, Redirect URI or Callback URL.

應(yīng)用程序注冊完成后， Authorization Server會生成客戶端賬號信息(client identifier和client secret),。 Client ID是一個公共的字符串被service用來唯一區(qū)別應(yīng)用程序,， 以及被用來構(gòu)建authorization URL; Client secret被用來當(dāng)應(yīng)用程序請求訪問用戶賬號時驗證應(yīng)用程序的身份, client secret不能被公開。
?

Authorization Grant

OAuth2定義了四種授權(quán)類型：

• Authorization Code: 應(yīng)用于server-side應(yīng)用程序
• Implicit: 應(yīng)用于手機(jī)App或Web應(yīng)用程序
• Resource Owner Password Credentials: 應(yīng)用于可信應(yīng)用程序
• Client Credentials: 應(yīng)用于應(yīng)用程序API訪問

?
Authorization Code
授權(quán)類型authorization code是使用最廣泛的因為它是面向服務(wù)端應(yīng)用,， 并且源代碼不會公開,， 因此不會暴露client secret。 它是基于重定向的,， 表明應(yīng)用程序必須可以和用戶代理交互并接受通過用戶代理展示的授權(quán)碼,。

授權(quán)過程如下：

1. 應(yīng)用程序發(fā)起授權(quán)請求
   授權(quán)請求鏈接類似：

https://cloud./v1/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

2. 用戶授權(quán)應(yīng)用程序
3. Authorization Server生成授權(quán)碼
   用戶點擊"Authorize Aplication" 授權(quán)應(yīng)用程序后， Authorization server會重定向用戶代理到應(yīng)用程序注冊時指定的重定向url,， 重定向鏈接中包含授權(quán)碼：

https:///callback?code=AUTHORIZATION_CODE

4. 應(yīng)用程序使用授權(quán)碼請求Access Token
   應(yīng)用程序通過API訪問請求access token, 請求攜帶授權(quán)碼(authorization code)以及client secret,， API類似如下：

https://cloud./v1/oauth/token?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=CALLBACK_URL

5. Authorization Server生成Access Token
   如果驗證通過， API會返回access token給應(yīng)用程序,， 結(jié)果類似如下：

{"access_token":"ACCESS_TOKEN","token_type":"bearer","expires_in":2592000,"refresh_token":"REFRESH_TOKEN","scope":"read","uid":100101,"info":{"name":"Mark E. Mark","email":"[email protected]"}}

接下來應(yīng)用程序就已經(jīng)被授權(quán)了,， 應(yīng)用程序訪問被保護(hù)用戶賬號時必須攜帶access token， 所具有的的權(quán)限限定于scope指定的范圍,。
如果同時返回的還有refresh token,， 則當(dāng)access token過期時可以請求生成新的access token。
?

Implicit
適用于手機(jī)應(yīng)用或web應(yīng)用（運行于瀏覽器中的應(yīng)用）,， 這個場景下client secret的安全性得不到保障,。這個也是基于重定向的。 這個過程不會驗證應(yīng)用程序的身份,， 而是依賴重定向URL驗證應(yīng)用程序的身份,。
這個授權(quán)方式不支持refresh token。

授權(quán)過程：

1. 應(yīng)用程序發(fā)出授權(quán)請求,， 這個授權(quán)請求鏈接類似授權(quán)碼的授權(quán)鏈接,， 除了這個請求的是token而不是code

https://cloud./v1/oauth/authorize?response_type=token&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

2. 用戶授權(quán)應(yīng)用程序
   用戶點擊同意授權(quán)應(yīng)用程序， 用戶必須首先登錄被保護(hù)的用戶賬號,。
3. 用戶代理通過重定向URI接收access token
   用戶點擊同意授權(quán)后,， Authorization server會重定向用戶代理到應(yīng)用程序制定的重定向URI并且包含access token

https:///callback#token=ACCESS_TOKEN

4. 用戶代理跟隨重定向URI但是保留access token, 之后應(yīng)用程序從URL重取出access token。
   ?

Resource Owner Password Credentials
用戶直接提供被保護(hù)的用戶賬號的賬號密碼給應(yīng)用程序,， 應(yīng)用程序使用這個賬號信息去獲取access token,。這種授權(quán)方式應(yīng)當(dāng)僅在其他方式不能使用的時候使用,。 并且應(yīng)該只在可信的應(yīng)用程序中使用, 比如Authorization server中的程序。
授權(quán)鏈接通常如下：

https://oauth./token?grant_type=password&username=USERNAME&password=PASSWORD&client_id=CLIENT_ID

?

Client Credentials
這種授權(quán)方式使得應(yīng)用程序可以訪問它自己的服務(wù)賬號,， 在應(yīng)用程序需要更新注冊信息時有用,， 比如描述信息或重定向URI，或者其他信息,。
應(yīng)用程序向authorization server請求access token并攜帶client id和client secret,。
連接通常如下：

https://oauth./token?grant_type=client_credentials&client_id=CLIENT_ID&client_secret=CLIENT_SECRET

Access token使用案例：

curl -X POST -H "Authorization: Bearer ACCESS_TOKEN""https://api./v2/$OBJECT" 

Refresh token使用案例：

https://cloud./v1/oauth/token?grant_type=refresh_token&client_id=CLIENT_ID&client_secret=CLIENT_SECRET&refresh_token=REFRESH_TOKEN

https://www./community/tutorials/an-introduction-to-oauth-2

OAuth Scopes
就是授權(quán)頁面上app請求的權(quán)限，這是開發(fā)者寫死的權(quán)限,。

示例access_token:

{
  "access_token":"MTQ0NjJkZmQ5OTM2NDE1ZTZjNGZmZjI3",
  "token_type":"bearer", // token類型
  "expires_in":3600,// 如果token有過期時間,，則應(yīng)該在過期時間內(nèi)使用token
  "refresh_token":"IwOGYzYTlmM2YxOTQ5MGE3YmNmMDFkNTVk", // 獲取新的access_token所用，但是implicit grant沒有refresh token
  "scope":"create"
}

https://www./oauth2-servers/access-tokens/access-token-response/

?
?

OpenID Connect

OpenID Connect1.0是基于OAuth2.0協(xié)議的簡單身份層,，允許客戶端確定已被Authorization Server驗證過的終端用戶的身份,，以及可以以Restful方式獲取終端用戶的基本資料(basic profile information).

OpenID Connect允許所有類型的客戶端，包括Web, mobile, JavaScript客戶端,。

OpenID Connect和OpenID2.0做了很多相似的工作,，但是OpenID Connect是以一種API友好的方式。

AUth1.0a和OpenID2.0集成需要擴(kuò)展,，而OAuth2.0的功能是集成在OpenID Connect協(xié)議中的,。

一個完整的Open ID Connect的過程如下：

1. 查找OIDC元信息(通常地址為site/.well-known/openid-configuration)
2. 執(zhí)行OAuth流獲取id token以及access token
3. 訪問JWKS終點獲取JWT簽名密鑰并且可選擇地注冊客戶端應(yīng)用
4. 驗證JWT ID token(即上文的id token)
5. 通過access token訪問UserInfo終點獲取用戶信息

?

Identity Token

ID token類似于身份證， 是一個標(biāo)準(zhǔn)的JWT格式的由OpenID Provider(OP)提供的字符串,。
ID token中包含的內(nèi)容：

• 用戶的身份,，subject(sub)
• 簽發(fā)的授權(quán)機(jī)構(gòu)(iss)
• 所屬的客戶端, audience或者client(aud)
• 可選包含一個隨機(jī)數(shù)(nonce)
• 可選包含簽發(fā)時間(auth_time)，以及強度(acr)
• 簽發(fā)時間(iat)以及過期時間(exp)
• 可選包含額外的用戶信息,， 如名稱,， 郵箱地址等

ID token由header, body, signature三部分組成， 以點(.)分隔,，每部分都經(jīng)base 64轉(zhuǎn)碼過,。

OpenID Connect授權(quán)流：

• Authorization code flow: 最普遍使用的情況， 通常使用在傳統(tǒng)web應(yīng)用,， 手機(jī)app上,。首先重定向用戶到OP(Open Identity Proider)進(jìn)行用戶驗證并授權(quán)， 然后后臺發(fā)送請求獲取id token,。 這個方法提供了最好的安全性,， 因為token不會傳送到瀏覽器中。
• Implicit flow: 為基于瀏覽器的,， 無后臺的app應(yīng)用,。 ID Token直接包含在OP 返回的重定向響應(yīng)中。
• Hybrid flow: 很少使用,， 允許前臺,， 后臺各自請求token,， 是以上兩種的組合,。

OpenID Authorisation code flow詳解
分為兩步： 1,， 驗證用戶， 請求用戶同意,， 獲取授權(quán)碼,， 2， 可選地驗證客戶端,， 使用授權(quán)碼獲取token
一,、
重定向用戶到OAuth2.0的授權(quán)端點(authorisation endpoint)驗證用戶。 OpenID驗證請求實際上是OAuth2.0的獲取用戶信息的授權(quán)請求,， 通過在scope中包含openid字段,。

HTTP/1.1 302 Found
Location: https://openid./login?
          response_type=code
          &scope=openid
          &client_id=s6BhdRkqt3
          &state=af0ifjsldkj
          &redirect_uri=https://client./cb

在OP端檢查用戶是否已登錄， 未登錄則提示登錄
然后OP會調(diào)用客戶端應(yīng)用的redirect_uri并返回authorisation code或者error code

Authorisation code是一個中間碼,， 客戶端應(yīng)用需要提交這個code到OP獲取ID token,， 這個可以直接通過后臺請求完成， 以避免暴露私密信息和token,。
用code交換id token發(fā)生在OP的token端點,。
Client ID和client secret通過Authorization頭部傳遞， OpenID Connect也支持通過JWT驗證,。
Token請求通常如下：

POST /token HTTP/1.1
Host: openid.
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

grant_type=authorization_code
 &code=SplxlOBeZQQYbYS6WxSbIA
 &redirect_uri=https://client./c

如果請求成功,， 結(jié)果通常是包括ID token， access token和可選的refresh token的json對象,。
對于一個基礎(chǔ)的OpenID驗證請求,， 通常只有ID token是需要的， access token可以被忽略,， 不過access token也可以用來獲取用戶的信息,， 通過UserInfo端點。

?
ID token的用途：

• 無狀態(tài)的session,， 可以放進(jìn)瀏覽器的cookie中實現(xiàn)輕量級的無狀態(tài)的session,， 避免了在服務(wù)器端存儲session的必要。
• 傳遞給第三方： 當(dāng)其他應(yīng)用活動后臺服務(wù)需要知道用戶的身份信息時,， 可以把ID Token傳遞給它們,。
• Token exchange: 可以使用ID token交換access token. Token exchange使用在分布式應(yīng)用中。
  ?

OpenID well known endpoint
OIDC providers可以支持’well known’端點,， 這是一個包含可以讓客戶端自行配置的json對象,， 有些內(nèi)容不會變化， 有些會定期變化,。

https:///.well-known/openid-configuration

一般情況下,， 可以使用OpenId Connect替代OAuth2.

https:///learn/openid-connect#example-auth-code-flow-step-1
https://www./blog/openid-connect-explained-in-plain-english
https:///learn/openid-connect#example-auth-code-flow-step-1

?

擴(kuò)展知識：

OpenID Connect Authorization Code Flow

1. 客戶端準(zhǔn)備一個驗證請求,，包括一些用戶指定的參數(shù)
2. 客戶端發(fā)送請求到Authorization Server
3. Authorization Server驗證用戶賬號，并獲取用戶的授權(quán)后返回Authorization Code
4. 客戶端利用Authorization code向token端點發(fā)請求
5. 客戶端收到包括ID Token和Access Token的響應(yīng)
6. 客戶單驗證ID Token,，并且獲取終端用戶的身份標(biāo)識(Subject Identifier)

驗證ID Token和Access Token

ID Token驗證

1. 通過客戶端注冊時的key和algorithm解密ID Token
2. 驗證iss字段(issuer claim)
3. 驗證aud字段,，aud字段必須包含client_id
4. 如果有多個audience, 響應(yīng)必須包含azp
5. 如果有azp字段，值必須是client_id
6. 其他包括驗證alg, iat, nonce等字段

Access Token驗證

在使用Authorization Code Flow時,，如果ID Token包含at_hash字段,，則客戶端必須用它取校驗Access Token，驗證過程和Implicit Flow使用的一樣,，但是使用的是從Token Endpoint返回的ID Token和Access Token,。

1. 使用ID Token中指定的算法對access_token進(jìn)行hash
2. 取hash的左半部分并且base64url encode
3. at_hash的值必須和第二步算出的值相等

?

Implicit Authorization Flow

1. 客戶端準(zhǔn)備驗證請求，包含指定的參數(shù)
2. 客戶端發(fā)送請求到Authorization Server
3. Authorization驗證用戶賬號,，并且獲取用戶授權(quán),，然后重定向用戶到一個指定地址，url里包含ID Token,，如果請求參數(shù)里指定了需要Access Token,，則url里還有Access Token。
4. 客戶端驗證ID Token并獲取用戶身份標(biāo)識(Subject Identifier)

驗證ID Token和Access Token

驗證過程和Authorization Code Flow相同

?

Hybrid Authentication Flow

1. 客戶端準(zhǔn)備驗證請求,，并帶有指定的參數(shù)
2. 客戶端發(fā)送請求到Authorization Server
3. Authorization驗證用戶賬號并取得用戶授權(quán),，然后返回給客戶端Authorization Code，根據(jù)指定的Response Type,，也可以有一個或多個其他的參數(shù)
4. 客戶端利用Authorization Code向Token Endpoint發(fā)送請求,，Token Endpoint返回ID Token和Access Token.
5. 客戶端驗證ID Token，并取得用戶標(biāo)識

當(dāng)使用Hybrid Flow驗證流程時,，Authorization Endpoint的使用和Authorization Code Flow相同,，除了一個參數(shù)例外：

response_type: Oauth2.0 response_type決定了將使用的驗證流程。當(dāng)使用Hybrid Flow時,，response_type值可能為code id_token, code token或者code id_token token.

Hybrid Flow Authorization Endpoint返回的值包括以下這些：

access_token: OAuth2.0 Access Token,，當(dāng)response_type是code token, code id_token token時

id_token: ID Token，當(dāng)response_type是code id_token或者code id_token token時

code: Authorization Code, Hybrid Flow總是返回這個,。

示例:

GET /authorize?
response_type=code id_token
&client_id=s6BhdRkqt3
&redirect_uri=https://client./cb
&scope=openid profile email
&nonce=n-0S6_WzA2Mj
&state=af0ifjsldkj HTTP/1.1
Host: server.

 HTTP/1.1 302 Found
 Location: https://client./cb#
 code=SplxlOBeZQQYbYS6WxSbIA
 &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
 &state=af0ifjsldkj

想必看到這里大家也明白了Hybrid混合的意思,。即可以返回多個token和code, code還可以用來向token Endpoint請求access_token。

Id_token和access_token的驗證方式和上文一樣,。

code校驗流程：

1. 使用ID Token頭指定的算法hash code的值
2. 取左邊一半的hash值,，然后base64url encode
3. 比較c_hash字段的值必須和上一步算出的結(jié)果相同

https:///specs/openid-connect-core-1_0.htm