# OpenID And OAuth2.0

> 學習自YouTube影片：[OpenID Connect - Basics](https://www.youtube.com/watch?v=VI3G4Quzsb8&t=363s)

## OpenID Connect - Basics

### Highlights
- OpenID Connect是OAuth2.0的一個配置
- OAuth2.0是授權協定，OpenID是在它之上的一個配置，用來取得詳細資訊。
- OpenID Connect是在OAuth2.0之上的身份層
- OAuth2.0預設並不知道程式使用者是誰，OpenID就是建構在OAuth2.0之上用來取得使用者資訊和管理使用者Session
- OpenID Connect典型使用案例是社群登入和Identity Federation
- 社群登入指的是FB或Google登入按鈕
- Identity Federation是登入到網域的使用者也可以SSO到不同的網域
- Identity Federation可以參考 [Identity Federation — a brief introduction](https://dinika-15.medium.com/identity-federation-a-brief-introduction-f2f823f8795a)、[Identity federation in AWS](https://aws.amazon.com/tw/identity/federation/)
- 提供公開文件和自動化認證測試套件
- 若正在實作一個OpenID connect server，可以在該Server上跑這些測試，以通過認證
- 不必要作公開認證，但跑這些測試，可以驗證Server是否已經完整實作OpenID的協定
- 了解起始點
- https://openid.net/connect/
- 在所有規格中，核心"Core"應該先閱讀

### OAuth 2.0概念
- response_type：定義code和token
- grant_type：有4種授權類型
- authorization_code
- refresh_token
- ropc (resource owner password credentials)
- client_credentials
- scope：引入範圍的概念，沒有任何值
- token：發行2種token
- access_token
- refresh_token
- 沒有身份識別 (資源擁有者)
- 沒有指定任何受保護的資源

### 在OAuth 2.0之上的OpenID Connect
- response_type：同樣支援code和token，並引入更多的response type：code token, code id_token, id_token token,code id_token token
- grant_type：沒有增加grant type，反而移除了ropc和client_credentials (很多開發者想用OpenID Connect取得這2種授權，卻出現錯誤，即是因為OpenID不支援這2種類型)
- scope：部份在OAuth2.0之上的配置是已經定義了scope，openid profile email phone address (offline_access)
- OpenID connect作用像是個開關，它告知授權伺服器，這是一個OpenID的呼叫，所有設定的scope都應在OpenID連接的情境下處理；若不是OpenID，則由授權伺服器決定，所以在大部份的實作中，有這個scope，則將呼叫由OAuth2.0切換到OpenID中
- token：同樣有access_token和refresh_token，但增加了id_token (如下個項目)
- identifier for resource_owners(users)：id_token (JSON Web Token, JWT)
- 這是用來識別資源使用者
- resource endpoints
- 受保護的使用者資訊端點，它會回傳目前的使用者詳細資料
- 這裡的重點在OpenID connect工作小組最近決定遠離隱含工作流，這表示不應再使用token作為授權請求的存取token結果，所以應避免使用code token, id_token token, code id_token token，而只關注在code, id token和code id_token

### Basics II

- Authorization Server：用來發行token、授權或接收資源使用者作的授權決定
- 授權伺服器發行refresh token和access token給client應用程式，但要再加上id token
- refresh token是唯一在client和授權伺服器之間作交換
- access token從授權伺服器接收到後，用來存取受保護的資源，在OpenID的使用情境下，就是用來呼叫使用者資訊端點 (取得目前使用者詳細資料)
- id_token也是唯一在client和授權伺服器間使用 (在其他影片會介紹它的使用案例)，目前它並不是用來存取受限制的資源
- id_token的內容，包含不同的claims
- iss: the issuer (誰發行這個token)
- **重點：它指向授權伺服器**
- aud: audience, who requested it (誰接收或請求了這個token)
- **重點：它指向client app，通常是client id**
- sub: subject, who is represented (在大部份案例中，它是resource owner)
- **重點：它指向資源使用者**
- iat: issued at (何時被發行)
- exp: expiration time (何時逾時)
- at_hash: related to access_token (被雜湊過的access token，同時間發行，所以id_token和access_token之間是有關聯的)
- 因為id_token包含iss, aud, sub，它們指向3個重要的實體，並且把它們繫結起來，而且id_token通常以JWT(json web token)型式呈現，它也是一種數位簽章，所以client應用程式可以驗證這個token，並且知道這些值是正確的

### First request - response
- 這裡使用的response type是code，唯一用來辨識它是一個OpenID connect的呼叫是它包含scope，否則它只單單只是OAuth2.0的呼叫
- 在接收到授權碼後，client會進行code交換請求，這個呼叫就和OAuth2.0完全一樣
- Token的回應會包含在OAuth2.0所有已知的值，再加上id_token
- 所以你若已經有配置好OAuth2.0的client，唯一的事情是使用不同的scopes和取出id_token，有這些元素後，就能夠使用這個access_token，來呼叫使用者資訊端點，以取得使用者詳細資訊，並且使用id_token作為使用者的識別

### 資源連結
- OpenID Connect: https://openid.net/connect
- OpenID Connect certifications: https://openid.net/certification/instructions/
- Loginbuddy test site: https://client.loginbuddy.net

### 其他閱讀
- [各大網站 OAuth 2.0 實作差異](https://blog.yorkxin.org/posts/oauth2-implementation-differences-among-famous-sites.html)
- [[ASP.NET Core] Identity Server 4 - Concepts](https://karatejb.blogspot.com/2019/11/aspnet-core-identity-server-4-concepts.html)