keycloak~OIDC&OAuth2&自定义皮肤

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 主要术语

1. EU：End User：一个人类用户。
2. RP：Relying Party ,用来代指OAuth2中的受信任的客户端，身份认证和授权信息的消费方；
3. OP：OpenID Provider，有能力提供EU认证的服务（比如OAuth2中的授权服务），用来为RP提供EU的身份认证信息；
4. ID Token：JWT格式的数据，包含EU身份认证的信息。
5. UserInfo Endpoint：用户信息接口（受OAuth2保护），当RP使用Access Token访问时，返回授权用户的信息，此接口必须使用HTTPS。
   2.4 OIDC 工作流程
   从抽象的角度来看，OIDC的流程由以下5个步骤构成：
6. RP发送一个认证请求给OP；
7. OP对EU进行身份认证，然后提供授权；
8. OP把ID Token和Access Token（需要的话）返回给RP；
9. RP使用Access Token发送一个请求UserInfo EndPoint；
10. UserInfo EndPoint返回EU的Claims。
    

3 登录统一
对于用户的登陆，keycloak是统一控制的，如果希望做个性化的处理，需要自己去开发css文件，生成对应的皮肤，然后在helm配置中去指定。

3.1 自定义皮肤
对于多个客户端来说，只要对接了keycloak，这们都会跳到统一的keycloak登陆页去认证。
3.1.1 Realm作用域皮肤

3.1.2 Client客户端的皮肤

3.2 登录重定向
在客户端配置时，需要指定客户端的重定向地址，当登录完成后，会重定向回来，这个配置我们可以是通配符或者是指定的地址，如下：

当你设置时指定地址后，你无法在客户端进行重写，如果你的重定向地址与keycloak配置的不同时，将出现下面错误：

而如果你设置为通配符时，你是可以在客户端程序里去重写它的。

我们可以在程序的配置里重写这个地址，只要符合通配符规则即可。