1 OpenID & OAuth2 & SAML
1.1 相關資料
https://github.com/keycloak/keycloak
https://www.keycloak.org/docs/latest/server_development
https://docs.cbioportal.org/2.2-authorization-and-authentication/authenticating-and-authorizing-users-via-keycloak
https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.3/html/server_developer_guide/providers
https://www.baeldung.com/java-keycloak-custom-user-providers
1.2 OpenID
OpenID是一種認證標准，互聯網上有很多賬戶都是支持OpenID比如谷歌、雅虎、PayPal等等。
用戶要使用OpenID就必須先在OpenID身份服務器（Identity Provider， IDP）獲得OpenID 賬號（比如Google賬戶）。用戶可以使用OpenID賬戶來登錄任何一個接受OpenID認證的服務應用（the relying party，RP，依賴方）。OpenID協議標准就是提供一個框架用來IDP和RP之間通信。
本質而言，用戶的OpenID是一個為用戶個人所擁有的特殊URL(比如 alice2016.openid.com)，所以有些網站甚至會提供選項讓用戶自己去填寫OpenID。
1.3 OAuth2
准確來講，OAuth2是一個授權的標准協議。也許會令人困惑，OAuth2是OpenID-Connect的基礎，但是OpenID-Connect是認證協議（在OpenID-Connect中，ID-Token也被當做是一種資源）。
讓我們回到OAuth2，OAuth2提供了一種代理訪問機制，也就是說一個應用（可以被稱為客戶端）可以代替用戶到資源服務器上獲得屬於用戶的資源或是進行符合用戶權限的操作 ，而用戶不用將自己的用戶名和口令等身份憑據分享給客戶端。OAuth2是通過IDP給第三方應用頒發令牌（Token）來實現以上功能的，第三方應用通過使用令牌向資源服務換取對應的資源。
在Twitter的OAuth指導手冊中說OAuth2是一種認證協議，實際上，這是基於授權的“偽認證”。
1.4 SAML
SAML協議是三者中時間最長的協議，最初版本制定於2001年，並於2005年修改。作為一種安全性斷言標記語言，SAML協議既可以用於認證也用於授權。
所謂的安全性斷言，就是關於認證、授權以及用戶屬性（比如用用戶的有效或者住址等信息）的聲明集合，在SAML中，這些斷言以XML的格式傳輸。
1.5 三者對比
2 OIDC
OIDC是OpenID Connect的簡稱，OIDC=(Identity, Authentication) + OAuth 2.0。它在OAuth2上構建了一個身份層，是一個基於OAuth2協議的身份認證標准協議。我們都知道OAuth2是一個授權協議，它無法提供完善的身份認證功能（關於這一點請參考[認證授權] 3.基於OAuth2的認證（譯）），OIDC使用OAuth2的授權服務器來為第三方客戶端提供用戶的身份認證，並把對應的身份認證信息傳遞給客戶端，且可以適用於各種類型的客戶端（比如服務端應用，移動APP，JS應用），且完全兼容OAuth2，也就是說你搭建了一個OIDC的服務后，也可以當作一個OAuth2的服務來用。
2.1 場景圖
2.2 OIDC 核心概念
OAuth2提供了Access Token來解決授權第三方客戶端訪問受保護資源的問題；OIDC在這個基礎上提供了ID Token來解決第三方客戶端標識用戶身份認證的問題。OIDC的核心在於在OAuth2的授權流程中，一並提供用戶的身份認證信息（ID Token）給到第三方客戶端，ID Token使用JWT格式來包裝，得益於JWT（JSON Web Token）的自包含性，緊湊性以及防篡改機制，使得ID Token可以安全的傳遞給第三方客戶端程序並且容易被驗證。此外還提供了UserInfo的接口，用戶獲取用戶的更完整的信息。
2.3 OIDC 主要術語
- EU：End User：一個人類用戶。
- RP：Relying Party ,用來代指OAuth2中的受信任的客戶端，身份認證和授權信息的消費方；
- OP：OpenID Provider，有能力提供EU認證的服務（比如OAuth2中的授權服務），用來為RP提供EU的身份認證信息；
- ID Token：JWT格式的數據，包含EU身份認證的信息。
- UserInfo Endpoint：用戶信息接口（受OAuth2保護），當RP使用Access Token訪問時，返回授權用戶的信息，此接口必須使用HTTPS。
2.4 OIDC 工作流程
從抽象的角度來看，OIDC的流程由以下5個步驟構成： - RP發送一個認證請求給OP；
- OP對EU進行身份認證，然后提供授權；
- OP把ID Token和Access Token（需要的話）返回給RP；
- RP使用Access Token發送一個請求UserInfo EndPoint；
- UserInfo EndPoint返回EU的Claims。
3 登錄統一
對於用戶的登陸，keycloak是統一控制的，如果希望做個性化的處理，需要自己去開發css文件，生成對應的皮膚，然后在helm配置中去指定。
3.1 自定義皮膚
對於多個客戶端來說，只要對接了keycloak，這們都會跳到統一的keycloak登陸頁去認證。
3.1.1 Realm作用域皮膚
3.1.2 Client客戶端的皮膚
3.2 登錄重定向
在客戶端配置時，需要指定客戶端的重定向地址，當登錄完成后，會重定向回來，這個配置我們可以是通配符或者是指定的地址，如下：
當你設置時指定地址后，你無法在客戶端進行重寫，如果你的重定向地址與keycloak配置的不同時，將出現下面錯誤：
而如果你設置為通配符時，你是可以在客戶端程序里去重寫它的。
我們可以在程序的配置里重寫這個地址，只要符合通配符規則即可。
