├── .nojekyll ├── SSO ├── authentik │ └── README.md ├── CAS │ └── README.md ├── Pac4j │ └── README.md ├── Keycloak │ └── README.md ├── Hydra │ └── README.md └── README.md ├── INTRODUCTION.md ├── 多租户 ├── 通用多租户框架.md └── README.md ├── 认证基础 ├── HTTP │ ├── HTTP 认证.md │ └── Session.md ├── README.md ├── JWT │ ├── 99~参考资料 │ │ └── 2023~Stop using JSON Web tokens for user sessions.md │ └── JWT.md └── 99~参考资料 │ └── 2023-Password, Session, Cookie, Token, JWT, SSO, OAuth - Authentication Explained.md ├── IAM 平台 ├── 扫码登陆.md └── README.md ├── OAuth ├── 99~参考资料 │ ├── mrcode~OAuth 2.0 实战 │ │ └── README.md │ └── 2022~Sheng~OAuth 2.0 协议.md ├── README.md ├── OIDC │ └── 99~参考资料 │ │ └── 2021~Sheng~OIDC 协议.md └── 深入理解现代身份认证与授权：ID Token、Access Token、OAuth 和 OIDC.md ├── RBAC └── README.md ├── .gitattributes ├── .gitignore ├── README.md ├── LDAP └── README.md ├── index.html ├── _sidebar.md └── LICENSE /.nojekyll: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /SSO/authentik/README.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /INTRODUCTION.md: -------------------------------------------------------------------------------- 1 | # 本篇导读 2 | -------------------------------------------------------------------------------- /SSO/CAS/README.md: -------------------------------------------------------------------------------- 1 | # CAS 2 | -------------------------------------------------------------------------------- /多租户/通用多租户框架.md: -------------------------------------------------------------------------------- 1 | # 通用多租户框架 2 | -------------------------------------------------------------------------------- /SSO/Pac4j/README.md: -------------------------------------------------------------------------------- 1 | # Pac4j 2 | -------------------------------------------------------------------------------- /SSO/Keycloak/README.md: -------------------------------------------------------------------------------- 1 | # Keycloak 2 | -------------------------------------------------------------------------------- /认证基础/HTTP/HTTP 认证.md: -------------------------------------------------------------------------------- 1 | # HTTP 认证 2 | -------------------------------------------------------------------------------- /IAM 平台/扫码登陆.md: -------------------------------------------------------------------------------- 1 | # 扫码登陆 2 | 3 | # Links 4 | 5 | - https://mp.weixin.qq.com/s/xVk2hGnBRRCgtL9tYWWarw 6 | -------------------------------------------------------------------------------- /OAuth/99~参考资料/mrcode~OAuth 2.0 实战/README.md: -------------------------------------------------------------------------------- 1 | > [原文地址](https://zq99299.github.io/note-book/oath2/) 2 | -------------------------------------------------------------------------------- /IAM 平台/README.md: -------------------------------------------------------------------------------- 1 | # 开放平台 2 | 3 | # Links 4 | 5 | - https://mp.weixin.qq.com/s/EToZ5wqfQCevmgRwdEWdcg 6 | -------------------------------------------------------------------------------- /RBAC/README.md: -------------------------------------------------------------------------------- 1 | # 基于角色的权限控制 RBAC 2 | 3 | # Links 4 | 5 | - https://www.cnblogs.com/niuli1987/p/9871182.html 6 | -------------------------------------------------------------------------------- /.gitattributes: -------------------------------------------------------------------------------- 1 | *.xmind filter=lfs diff=lfs merge=lfs -text 2 | *.zip filter=lfs diff=lfs merge=lfs -text 3 | *.pdf filter=lfs diff=lfs merge=lfs -text 4 | -------------------------------------------------------------------------------- /认证基础/README.md: -------------------------------------------------------------------------------- 1 | # 常见 Web 认证方式对比 2 | 3 | # Links 4 | 5 | - Web Authentication Methods Compared https://testdriven.io/blog/web-authentication-methods/ 6 | 7 | - 聊聊Web Api 认证方案那点儿事 https://cubox.pro/c/4uLibA -------------------------------------------------------------------------------- /认证基础/HTTP/Session.md: -------------------------------------------------------------------------------- 1 | # Session 2 | 3 | 互联网服务离不开用户认证。一般流程是下面这样。 4 | 5 | 1、用户向服务器发送用户名和密码。 6 | 7 | 2、服务器验证通过后，在当前对话（session）里面保存相关数据，比如用户角色、登录时间等等。 8 | 9 | 3、服务器向用户返回一个 session_id，写入用户的 Cookie。 10 | 11 | 4、用户随后的每一次请求，都会通过 Cookie，将 session_id 传回服务器。 12 | 13 | 5、服务器收到 session_id，找到前期保存的数据，由此得知用户的身份。 14 | 15 | # Links 16 | 17 | - https://www.jianshu.com/p/25802021be63 18 | -------------------------------------------------------------------------------- /多租户/README.md: -------------------------------------------------------------------------------- 1 | # 多租户框架 2 | 3 | 租户的概念不止局限于集群的用户，它可以包含为一组计算，网络，存储等资源组成的工作负载集合。而在多租户集群中，需要在一个集群范围内（未来可能会是多集群）对不同的租户提供尽可能的安全隔离，以最大程度的避免恶意租户对其他租户的攻击，同时需要保证租户之间公平地分配共享集群资源。 4 | 5 | 在隔离的安全程度上，我们可以将其分为软隔离(Soft Multi-tenancy)和硬隔离（Hard Multi-tenancy）两种。其中软隔离更多的是面向企业内部的多租需求，该形态下默认不存在恶意租户，隔离的目的是为了内部团队间的业务保护和对可能的安全攻击进行防护；而硬隔离面向的更多是对外提供服务的服务供应商，由于该业务形态下无法保证不同租户中业务使用者的安全背景，我们默认认为租户之间以及租户与 K8s 系统之间是存在互相攻击的可能，因此这里也需要更严格的隔离作为安全保障。 6 | -------------------------------------------------------------------------------- /SSO/Hydra/README.md: -------------------------------------------------------------------------------- 1 | # Hydra 2 | 3 | 并非每个人都需要自托管的 OAuth2 解决方案，但若需要，可关注 Hydra。这是一款完全符合规范的开源 OAuth2 服务器及 OpenID 4 | connect 提供方。Hydra 具有用于开发环境的内存存储支持，以及用于生产环境的关系数据库（PostgreSQL）。无状态的 Hydra 平 5 | 台，拥有类似九头蛇海德拉的魔力（在希腊神话中，Hydra 意指九头蛇海德拉。即使斩断它的一颗头，也会生出新的头。与之类似，Hydra 平台中无状态的服务器实例出一旦失效，平台会创建新的实例。⸺译者注），且易于在 Kubernetes 等平台上进行横向伸缩。 6 | 根据性能要求，在对 Hydra 实例进行横向伸缩时，需要调整数据库实例的数量。由于 Hydra 并未提供任何开箱即用的身份管理解决方案，所以可以通过一个整洁的 API，将现有的任何身份管理系统，与 Hydra 集成在一起。这种清晰地将身份管理与 OAuth2 框架 7 | 其余部分相分离的设计，使 Hydra 与现有身份验证生态系统的集成更加容易。 8 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # Ignore all 2 | * 3 | 4 | # Unignore all with extensions 5 | !*.* 6 | 7 | # Unignore all dirs 8 | !*/ 9 | 10 | .DS_Store 11 | 12 | # Logs 13 | logs 14 | *.log 15 | npm-debug.log* 16 | yarn-debug.log* 17 | yarn-error.log* 18 | 19 | # Runtime data 20 | pids 21 | *.pid 22 | *.seed 23 | *.pid.lock 24 | 25 | # Directory for instrumented libs generated by jscoverage/JSCover 26 | lib-cov 27 | 28 | # Coverage directory used by tools like istanbul 29 | coverage 30 | 31 | # nyc test coverage 32 | .nyc_output 33 | 34 | # Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files) 35 | .grunt 36 | 37 | # Bower dependency directory (https://bower.io/) 38 | bower_components 39 | 40 | # node-waf configuration 41 | .lock-wscript 42 | 43 | # Compiled binary addons (https://nodejs.org/api/addons.html) 44 | build/Release 45 | 46 | # Dependency directories 47 | node_modules/ 48 | jspm_packages/ 49 | 50 | # TypeScript v1 declaration files 51 | typings/ 52 | 53 | # Optional npm cache directory 54 | .npm 55 | 56 | # Optional eslint cache 57 | .eslintcache 58 | 59 | # Optional REPL history 60 | .node_repl_history 61 | 62 | # Output of 'npm pack' 63 | *.tgz 64 | 65 | # Yarn Integrity file 66 | .yarn-integrity 67 | 68 | # dotenv environment variables file 69 | .env 70 | 71 | # next.js build output 72 | .next 73 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # 微服务下的权限控制 2 | 3 | ![BytebyteGo Design Secure System CheatSheet](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/uPic/Dr3xegxQBClU.webp) 4 | 5 | 在传统的单体架构中，单个服务保存所有的用户数据，可以校验用户，并在认证成功后创建 HTTP 会话。在微服务架构中，用户是在和服务集合交互，每个服务都有可能需要知道请求的用户是谁。一种朴素的解决方案是在微服务系统中应用与单体系统中相同的模式，但是问题就在于如何让所有的服务访问用户的数据。解决这个问题大致两个思路：若使用共享用户数据库时，更新数据库表会成为一个难题，因为所有服务必须同时升级以便能够对接修改后的表结构；若将相同的数据分发给所有服务时，当某个用户已经被认证，如何让每个服务知晓这个状态是一个问题。 6 | 7 | Borsos 指出，单点登录(SSO)方案可能看起来是一个好主意，但这意味着每个面向用户的服务都必须与认证服务交互，这会产生大量非常琐碎的网络流量，同时这个方案实现起来也相当复杂。在其他方面，选择 SSO 方案安全性会很好，用户登录状态是不透明的，可防止攻击者从状态中推断任何有用的信息。 8 | 9 | 分布式会话方案，原理主要是将关于用户认证的信息存储在共享存储中，且通常由用户会话作为 key 来实现的简单分布式哈希映射。当用户访问微服务时，用户数据可以从共享存储中获取。该解决方案的另一个优点是用户登录状态是不透明的。当使用分布式数据库时，它也是一个高度可用且可扩展的解决方案。这种方案的缺点在于共享存储需要一定保护机制，因此需要通过安全链接来访问，这时解决方案的实现就通常具有相当高的复杂性了。 10 | 11 | 客户端令牌方案，此令牌在客户端生成，由身份验证服务进行签名，并且必须包含足够的信息，以便可以在所有微服务中建立用户身份。令牌会附加到每个请求上，为微服务提供用户身份验证。这种解决方案的安全性相对较好，但身份验证注销是一个大问题，缓解这种情况的方法可以使用短期令牌和频繁检查认证服务等。对于客户端令牌的编码方案，Borsos 更喜欢使用 JSON Web Tokens(JWT)，它足够简单且库支持程度也比较好。 12 | 13 | 客户端令牌与 API 网关结合，这个方案意味着所有请求都通过网关，从而有效地隐藏了微服务。在请求时，网关将原始用户令牌转换为内部会话 ID 令牌。在这种情况下，注销就不是问题，因为网关可以在注销时撤销用户的令牌。这种方案虽然库支持程度比较好，但实现起来还是可能很复杂。 14 | 15 | Borsos 建议使用客户端令牌(使用 JWT)和 API 网关结合的方案，因为这个方案通常使用起来比较容易，且性能也不错。SSO 方案虽然能满足需求，但他认为还是应该避免使用。若分布式会话方案所需要的相关技术已经应用在你的场景上，那么这个方案也是比较有趣的。他同时强调在选择解决方案时应着重考虑注销的重要性。 16 | 17 | # Links 18 | 19 | - https://zhuanlan.zhihu.com/p/62336927 20 | - https://medium.com/@jcbaey/authentication-in-spa-reactjs-and-vuejs-the-right-way-e4a9ac5cd9a3 21 | - https://www.zhihu.com/question/342103776/answer/806983636 现在用的比较多的单点登录技术是什么？ 22 | - https://mp.weixin.qq.com/s/y8Hhrbiu8ZzN9_zXJgOGSw?from=groupmessage&isappinstalled=0 如何设计权限管理模块 23 | -------------------------------------------------------------------------------- /OAuth/README.md: -------------------------------------------------------------------------------- 1 | # OAuth 2 | 3 | 简单说，OAuth 就是一种授权机制。数据的所有者告诉系统，同意授权第三方应用进入系统，获取这些数据。系统从而产生一个短期的进入令牌（token），用来代替密码，供第三方应用使用。 4 | 5 | 令牌（token）与密码（password）的作用是一样的，都可以进入系统，但是有三点差异。 6 | 7 | - 令牌是短期的，到期会自动失效，用户自己无法修改。密码一般长期有效，用户不修改，就不会发生变化。 8 | - 令牌可以被数据所有者撤销，会立即失效。以上例而言，屋主可以随时取消快递员的令牌。密码一般不允许被他人撤销。 9 | - 令牌有权限范围（scope），比如只能进小区的二号门。对于网络服务来说，只读令牌就比读写令牌更安全。密码一般是完整权限。 10 | 11 | # 授权机制 12 | 13 | OAuth 2.0 规定了四种获得令牌的流程。你可以选择最适合自己的那一种，向第三方应用颁发令牌。 14 | 15 | ## 授权码 16 | 17 | ## 隐藏式 18 | 19 | 有些 Web 应用是纯前端应用，没有后端。这时就不能用上面的方式了，必须将令牌储存在前端。RFC 6749 就规定了第二种方式，允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤，所以称为（授权码）"隐藏式"（implicit）。第一步，A 网站提供一个链接，要求用户跳转到 B 网站，授权用户数据给 A 网站使用。 20 | 21 | ```url 22 | https://b.com/oauth/authorize?response_type=token& 23 | client_id=CLIENT_ID& 24 | redirect_uri=CALLBACK_URL& 25 | scope=read 26 | ``` 27 | 28 | 上面 URL 中，response_type 参数为 token，表示要求直接返回令牌。第二步，用户跳转到 B 网站，登录后同意给予 A 网站授权。这时，B 网站就会跳回 redirect_uri 参数指定的跳转网址，并且把令牌作为 URL 参数，传给 A 网站。 29 | 30 | ```url 31 | https://a.com/callback#token=ACCESS_TOKEN 32 | ``` 33 | 34 | 上面 URL 中，token 参数就是令牌，A 网站因此直接在前端拿到令牌。注意，令牌的位置是 URL 锚点（fragment），而不是查询字符串（querystring），这是因为 OAuth 2.0 允许跳转网址是 HTTP 协议，因此存在"中间人攻击"的风险，而浏览器跳转时，锚点不会发到服务器，就减少了泄漏令牌的风险。 35 | 36 | ## 密码式 37 | 38 | 如果你高度信任某个应用，RFC 6749 也允许用户把用户名和密码，直接告诉该应用。该应用就使用你的密码，申请令牌，这种方式称为"密码式"（password）。 39 | 40 | 第一步，A 网站要求用户提供 B 网站的用户名和密码。拿到以后，A 就直接向 B 请求令牌。 41 | 42 | ```sh 43 | https://oauth.b.com/token? 44 | grant_type=password& 45 | username=USERNAME& 46 | password=PASSWORD& 47 | client_id=CLIENT_ID 48 | ``` 49 | 50 | 上面 URL 中，grant_type 参数是授权方式，这里的 password 表示"密码式"，username 和 password 是 B 的用户名和密码。 51 | 52 | 第二步，B 网站验证身份通过后，直接给出令牌。注意，这时不需要跳转，而是把令牌放在 JSON 数据里面，作为 HTTP 回应，A 因此拿到令牌。这种方式需要用户给出自己的用户名/密码，显然风险很大，因此只适用于其他授权方式都无法采用的情况，而且必须是用户高度信任的应用。 53 | 54 | ## 凭证式 55 | 56 | 凭证式（client credentials），适用于没有前端的命令行应用，即在命令行下请求令牌。第一步，A 应用在命令行向 B 发出请求。 57 | 58 | ```sh 59 | https://oauth.b.com/token? 60 | grant_type=client_credentials& 61 | client_id=CLIENT_ID& 62 | client_secret=CLIENT_SECRET 63 | ``` 64 | 65 | 上面 URL 中，grant_type 参数等于 client_credentials 表示采用凭证式，client_id 和 client_secret 用来让 B 确认 A 的身份。第二步，B 网站验证通过以后，直接返回令牌。这种方式给出的令牌，是针对第三方应用的，而不是针对用户的，即有可能多个用户共享同一个令牌。 66 | 67 | # Links 68 | 69 | - http://www.ruanyifeng.com/blog/2019/04/oauth-grant-types.html 70 | - https://mp.weixin.qq.com/s/5iryI8e6bwVWDWU57TbYLg 71 | -------------------------------------------------------------------------------- /认证基础/JWT/99~参考资料/2023~Stop using JSON Web tokens for user sessions.md: -------------------------------------------------------------------------------- 1 | # Stop using JSON Web tokens for user sessions 2 | 3 | ## Introduction 4 | 5 | Modern web applications (so called single page applications) often utilize JSON Web tokens (JWTs) for session handling instead of cookies. However, in many cases, the logout mechanism is not effectively implemented. The most critical issue arises when an XSS vulnerability is discovered. 6 | 7 | > Why should we even _logout_ from a web application? 8 | 9 | For security reasons, it is advisable for users to log out from a web application once they have completed their tasks. This practice is particularly crucial for sensitive applications, such as online banking, as it reduces the attack surface and makes it significantly harder for an attacker to hijack another user’s session. 10 | 11 | Frequently, when a Logout function is present in the application and is implemented with JSON Web Tokens, the application stores the JWT in an insecure location, such as the JavaScript code itself or the local storage in the user’s browser. This approach is insecure because essential flags like `HTTPOnly`[1](https://ds-security.com/post/stop-using-jwts-for-sessions/#fn:1) are not supported. Consequently, this allows an attacker to use JavaScript to access tokens. Moreover, the logout function often merely overwrites the JWT on the client side, leaving user sessions valid until timeout. 12 | 13 | ## The worst part 14 | 15 | Once an attacker discovers a Cross-Site-Scripting (XSS) vulnerability within the application, it’s “GAME OVER.” The attacker can gain access to the JWT and exploit it to access the application in the context of another user. 16 | 17 | The “attack chain” is depicted in the following diagram and operates as follows: 18 | 19 | 1. The attacker exploits a stored XSS vulnerability within the web application (e.g., in a guest comment). 20 | 2. An admin logs into the web application. 21 | 3. The web server generates the JWT and sends it to the user. The browser stores the JWT and uses it to access the web server resources with admin permissions. 22 | 4. The admin navigates to the manipulated page `/stored_XSS` that contains the attacker’s injected JavaScript code. 23 | 5. The attacker’s JavaScript code is sent to the admin. 24 | 6. The malicious JavaScript code executes in the admin’s browser. The attacker’s JavaScript code steals the admin’s JWT and sends it to the attacker. 25 | 7. The attacker can access the web application using the admin’s JWT and perform privileged admin functions. 26 | 27 | ![Attack path exploiting XSS with JWTs.svg](https://ds-security.com/files/XSS_with_JWTs.svg) 28 | 29 | We have seen this vulnerability numeros times in security assessments. In my opinion single-page application have a serious design issue when they use JWTs for authentification. This attack would not be possible with a cookie based session mechanisn where attributes like `HttpOnly` would prevents injected JavaScript Code from accessing the JWTs. 30 | -------------------------------------------------------------------------------- /认证基础/JWT/JWT.md: -------------------------------------------------------------------------------- 1 | ![JWT](https://s2.ax1x.com/2020/01/06/lykdTf.png) 2 | 3 | # JWT 机制详解 4 | 5 | JWT 是 Auth0 提出的通过对 JSON 进行加密签名来实现授权验证的方案。与前文介绍的基于 Session 的机制相比，使用 JWT 可以省去服务端读取 Session 的步骤，因此 JWT 是用来取代服务端的 Session 而非客户端 Cookie 的方案，也更符合 RESTful 的规范。这样但是对于客户端（或 App 端）来说，为了保存用户授权信息，仍然需要通过 Cookie 或 localStorage/sessionStorage 等机制进行本地保存。JWT 也可以被广泛用于微服务场景下各个服务的认证，免去重复中心化认证的繁琐。 6 | 7 | # 背景分析 8 | 9 | Session 模式的问题在于，扩展性（scaling）不好。单机当然没有问题，如果是服务器集群，或者是跨域的服务导向架构，就要求 session 数据共享，每台服务器都能够读取 session。 10 | 11 | 举例来说，A 网站和 B 网站是同一家公司的关联服务。现在要求，用户只要在其中一个网站登录，再访问另一个网站就会自动登录，可能有以下的实现方式： 12 | 13 | - 一种解决方案是 session 数据持久化，写入数据库或别的持久层。各种服务收到请求后，都向持久层请求数据。这种方案的优点是架构清晰，缺点是工程量比较大。另外，持久层万一挂了，就会单点失败。 14 | 15 | - 另一种方案是服务器索性不保存 session 数据了，所有数据都保存在客户端，每次请求都发回服务器。JWT 就是这种方案的一个代表。 16 | 17 | # 组成结构 18 | 19 | JWT 的三个部分依次如下：Header（头部）、Payload（负载）、Signature（签名），编码之后的 JWT 就是简单的字符串，包含又 `.` 分割的三部分： 20 | 21 | ![JWT Token](https://s2.ax1x.com/2020/01/06/lyk3fe.png) 22 | 23 | ```js 24 | // 1. Header, 包括类别（typ）、加密算法（alg）； 25 | { 26 | "alg": "HS256", 27 | "typ": "JWT" 28 | } 29 | 30 | // 2. Payload, 包括需要传递的用户信息； 31 | { 32 | "sub": "1234567890", 33 | "name": "John Doe", 34 | "admin": true 35 | } 36 | 37 | // 3. Signature, 根据 alg 算法与私有秘钥进行加密得到的签名字串；这一段是最重要的敏感信息，只能在服务端解密； 38 | HMACSHA256( 39 | base64UrlEncode(header) + "." + 40 | base64UrlEncode(payload), 41 | SECREATE_KEY 42 | ) 43 | ``` 44 | 45 | Payload 部分也是一个 JSON 对象，用来存放实际需要传递的数据。JWT 规定了 7 个官方字段，供选用。 46 | 47 | - iss (issuer)：签发人 48 | - exp (expiration time)：过期时间 49 | - sub (subject)：主题 50 | - aud (audience)：受众 51 | - nbf (Not Before)：生效时间 52 | - iat (Issued At)：签发时间 53 | - jti (JWT ID)：编号 54 | 55 | 需要注意的是，JWT 默认是不加密，并且本身包含了认证信息，一旦泄露，任何人都可以获得该令牌的所有权限。为了减少盗用，JWT 的有效期应该设置得比较短。对于一些比较重要的权限，使用时应该再次对用户进行认证。并且由于服务器不保存 session 状态，因此无法在使用过程中废止某个 token，或者更改 token 的权限。也就是说，一旦 JWT 签发了，在到期之前就会始终有效，除非服务器部署额外的逻辑。 56 | 57 | # 处理流程 58 | 59 | 在使用过程中，服务端通过用户登录验证之后，将 Header+Claim 信息加密后得到第三段签名，然后将签名返回给客户端，在后续请求中，服务端只需要对用户请求中包含的 JWT 进行解码，即可验证是否可以授权用户获取相应信息，其原理如下图所示： 60 | 61 | ![JWT S2S 认证](https://s2.ax1x.com/2020/01/06/lykKw6.png) 62 | 63 | 以 [node/jsonwebtoken](https://github.com/auth0/node-jsonwebtoken) 为例，我们可以使用字符串密钥，或者加载 cert 文件: 64 | 65 | ```js 66 | const jwt = require("jsonwebtoken"); 67 | const token = jwt.sign({ foo: "bar" }, "shhhhh"); 68 | 69 | // sign with RSA SHA256 70 | const cert = fs.readFileSync("private.key"); 71 | const token = jwt.sign({ foo: "bar" }, cert, { algorithm: "RS256" }); 72 | 73 | // 设置过期时间 74 | jwt.sign( 75 | { 76 | exp: Math.floor(Date.now() / 1000) + 60 * 60, 77 | data: "foobar", 78 | }, 79 | "secret" 80 | ); 81 | ``` 82 | 83 | 在进行内容读取时，我们可以直接解码 Payload 部分获取用户信息，也可以对签名内容进行验证： 84 | 85 | ```js 86 | // 直接获取到 Payload 而忽略签名 87 | const decoded = jwt.decode(token); 88 | 89 | // 获取完整的 Payload 与 Header 90 | const decoded = jwt.decode(token, { complete: true }); 91 | console.log(decoded.header); 92 | console.log(decoded.payload); 93 | 94 | // 同步校验 Token 是否有效 95 | const decoded = jwt.verify(token, "shhhhh"); 96 | console.log(decoded.foo); // bar 97 | 98 | // 异步校验是否有效 99 | jwt.verify(token, "shhhhh", function (err, decoded) { 100 | console.log(decoded.foo); // bar 101 | }); 102 | ``` 103 | 104 | # Links 105 | 106 | - https://mp.weixin.qq.com/s/j-Ap_30PO8bSFUY3Q_RHcg 107 | -------------------------------------------------------------------------------- /OAuth/OIDC/99~参考资料/2021~Sheng~OIDC 协议.md: -------------------------------------------------------------------------------- 1 | # OIDC 协议详解 2 | 3 | OIDC 是 OpenID Connect 的简称，它是一个建立在 OAuth 2.0 基础上的身份认证标准协议。可以将 OIDC 理解为：身份认证 + 授权 + OAuth 2.0。 4 | 5 | **OIDC 的核心优势在于：它在 OAuth2 的基础上增加了一层身份认证功能。** 6 | 7 | 我们知道 OAuth2 主要是一个授权协议，它本身并不提供完善的身份认证功能。OIDC 巧妙地利用 OAuth2 的授权服务器，为第三方客户端提供用户的身份认证，并将相应的身份信息传递给客户端。 8 | 9 | OIDC 的 versatility（多功能性）体现在： 10 | 11 | - 适用于各种类型的客户端（如服务端应用、移动 APP、JS 应用等） 12 | - 完全兼容 OAuth2（这意味着你搭建的 OIDC 服务也可以当作 OAuth2 服务使用） 13 | 14 | 下图展示了 OIDC 的典型应用场景： 15 | 16 | ![OIDC应用场景](https://thinking-oss.oss-cn-beijing.aliyuncs.com/img/2021/10/202110101111139.png) 17 | 18 | ## OIDC 协议族：一个完整的生态系统 19 | 20 | OIDC 不是单一的协议，而是由多个规范组成的协议族。这些规范包括一个核心规范和多个可选的扩展规范： 21 | 22 | - **Core**：这是 OIDC 的核心，也是唯一的必选规范。它定义了 OIDC 的基本功能，包括如何在 OAuth 2.0 之上构建身份认证，以及如何使用 Claims 传递用户信息。 23 | 24 | - **Discovery**：这个可选规范允许客户端动态获取 OIDC 服务的元数据描述信息，比如支持哪些规范、接口地址等。 25 | 26 | - **Dynamic Registration**：另一个可选规范，使客户端能够动态注册到 OIDC 的 OpenID Provider (OP)。 27 | 28 | - **OAuth 2.0 Multiple Response Types**：这是对 OAuth2 的扩展，提供了几个新的 response_type。 29 | 30 | - **OAuth 2.0 Form Post Response Mode**：同样是对 OAuth2 的扩展，提供了一种基于表单的方式将数据 POST 给客户端。 31 | 32 | - **Session Management**：规定了 OIDC 服务如何管理会话信息。 33 | 34 | - **Front-Channel Logout**：定义了一种基于前端的注销机制。 35 | 36 | - **Back-Channel Logout**：定义了 Relying Party (RP) 和 OP 之间如何通过后端通信完成注销。 37 | 38 | 下图展示了 OIDC 的组成结构： 39 | 40 | ![OIDC组成结构](https://thinking-oss.oss-cn-beijing.aliyuncs.com/img/2021/10/202110101111003.png) 41 | 42 | 值得注意的是，OIDC 并非全新的技术，而是巧妙地融合了多种现有技术： 43 | 44 | - 借鉴了 OpenID 的身份标识概念 45 | - 采用了 OAuth2 的授权流程 46 | - 使用 JWT 格式封装数据 47 | 48 | ## OIDC 的核心概念 49 | 50 | OIDC 在 OAuth2 的基础上做了两个关键的扩展： 51 | 52 | - OAuth2 提供了 **Access Token** 来解决第三方客户端访问受保护资源的授权问题 53 | - OIDC 增加了 **ID Token** 来解决第三方客户端识别用户身份的认证问题 54 | 55 | OIDC 的核心创新在于：在 OAuth2 的授权流程中，同时提供用户的身份认证信息（ID Token）给第三方客户端。ID Token 采用 JWT 格式封装，具有以下优势： 56 | 57 | - 自包含性：token 本身包含了所有必要信息 58 | - 紧凑性：数据结构紧凑，便于传输 59 | - 防篡改机制：确保数据的完整性和真实性 60 | 61 | 这些特性使得 ID Token 可以安全地传递给第三方客户端并且易于验证。 62 | 63 | 此外，OIDC 还提供了 **UserInfo** 接口，用于获取用户的更详细信息。 64 | 65 | ### OIDC 中的关键术语 66 | 67 | 为了更好地理解 OIDC，我们需要熟悉以下术语： 68 | 69 | - **EU (End User)**：最终用户，即人类用户。 70 | - **RP (Relying Party)**：相当于 OAuth2 中的受信任客户端，是身份认证和授权信息的消费方。 71 | - **OP (OpenID Provider)**：能够为 EU 提供认证的服务，为 RP 提供 EU 的身份认证信息。 72 | - **ID Token**：采用 JWT 格式的数据，包含 EU 的身份认证信息。 73 | - **UserInfo Endpoint**：一个受 OAuth2 保护的用户信息接口。当 RP 使用 Access Token 访问时，返回授权用户的信息。该接口必须使用 HTTPS 协议。 74 | 75 | ### OIDC 的工作流程 76 | 77 | OIDC 的工作流程可以概括为以下五个步骤： 78 | 79 | 1. RP 向 OP 发送一个认证请求。 80 | 2. OP 对 EU 进行身份认证，并获取授权。 81 | 3. OP 将 ID Token 和 Access Token（如果需要）返回给 RP。 82 | 4. RP 使用 Access Token 向 UserInfo Endpoint 发送请求。 83 | 5. UserInfo Endpoint 返回 EU 的 Claims（用户信息）。 84 | 85 | 下图直观地展示了这个流程： 86 | 87 | ![OIDC工作流程](https://thinking-oss.oss-cn-beijing.aliyuncs.com/img/2021/10/202110101111497.jpg) 88 | 89 | 注：图中的 AuthN 代表 Authentication（认证），AuthZ 代表 Authorization（授权）。 90 | 91 | ### 深入理解 ID Token 92 | 93 | ID Token 是 OIDC 对 OAuth2 最重要的扩展。它是一个安全令牌，采用 JWT 格式，包含用户信息，由授权服务器提供。 94 | 95 | 一个典型的 ID Token 包含以下字段： 96 | 97 | - **iss (Issuer Identifier)**：必填。标识提供认证信息的服务提供商，通常是一个 HTTPS URL。 98 | - **sub (Subject Identifier)**：必填。标识用户的唯一标识，在 iss 范围内唯一。 99 | - **aud (Audience)**：必填。标识 ID Token 的接收者，必须包含 OAuth2 的 client_id。 100 | - **exp (Expiration time)**：必填。过期时间。 101 | - **iat (Issued At Time)**：必填。JWT 的构建时间。 102 | - **auth_time (Authentication Time)**：用户完成认证的时间。 103 | - **nonce**：RP 提供的随机字符串，用于防止重放攻击。 104 | - **acr (Authentication Context Class Reference)**：可选。用于标识认证上下文类。 105 | - **amr (Authentication Methods References)**：可选。表示一组认证方法。 106 | - **azp (Authorized party)**：可选。通常与 aud 一起使用，只在被认证方与受众不一致时使用。 107 | 108 | ### Access Token 与 ID Token 的区别 109 | 110 | 虽然两者都是 token，但它们的用途不同： 111 | 112 | - **Access Token** 用于授权第三方客户端访问受保护的资源。 113 | - **ID Token** 用于第三方客户端识别用户的身份。 114 | 115 | ### OIDC 的认证流程 116 | 117 | OIDC 支持三种主要的认证流程： 118 | 119 | - **Authorization Code Flow**：使用 OAuth2 的授权码来交换 ID Token 和 Access Token。 120 | - **Implicit Flow**：使用 OAuth2 的隐式流程直接获取 ID Token 和 Access Token。 121 | - **Hybrid Flow**：混合使用 Authorization Code Flow 和 Implicit Flow。 122 | 123 | 每种流程都有其适用场景，开发者可以根据具体需求选择合适的流程。 124 | 125 | 通过以上详细介绍，我们可以看到 OIDC 是如何在 OAuth2 的基础上，通过增加身份层来提供更完善的身份认证和授权解决方案的。它的灵活性和安全性使其成为现代身份认证的重要标准。 126 | -------------------------------------------------------------------------------- /LDAP/README.md: -------------------------------------------------------------------------------- 1 | # LDAP 2 | 3 | 轻量级目录访问协议（LDAP）是一种可帮助用户查找关于企业和人员等数据的协议。LDAP 有两大工作目标：一、将数据存储在 LDAP 目录中；二、对要访问目录的用户进行身份验证。它也为应用提供所需的通信语言，以便从目录服务收发信息。借助目录服务，用户可以访问网络中的企业、个人信息和其他数据的存储位置。 4 | 5 | LDAP 最常见的用法是提供一个集中位置来访问和管理目录服务。LDAP 让企业能够存储、管理和保护与该企业、其用户和资产有关的信息（比如用户名和密码）。它提供分层的信息结构，可以让用户快速、高效地访问存储内容，当企业在扩大规模、吸纳了更多用户数据和资产时，这是一个相当重要的优势。 6 | 7 | LDAP 也可充当身份和访问管理（IAM）解决方案来满足用户身份验证的需要，支持 Kerberos 和单点登录（SSO）、简单身份验证安全层（SASL）和安全套接字层（SSL）。 8 | 9 | ## LDAP 与 Active Directory 10 | 11 | LDAP 是[微软](https://www.redhat.com/zh/partners/microsoft)的 Active Directory（AD）目录服务中使用的核心协议（但并非是其专用）；而 Active Directory 是一个大型目录服务数据库，包含网络中每一用户帐户的信息。更具体地说，LDAP 是目录访问协议（DAP）的轻量级版本，提供一个中央位置来访问和管理在传输控制协议/互联网协议（TCP/IP）上运行的目录服务，其最新版本是 LDAPv3。 12 | 13 | AD 提供身份验证以及用户和组管理，它是最终对用户或计算机执行身份验证的主体。这个数据库中包含的属性数量要比 LDAP 调用的数量多。不过，LDAP 擅长于使用少量信息来查找目录，因此不需要从 AD 提取它的全部属性，而且从哪一个目录服务调取也无关紧要。 14 | 15 | LDAP 的主要目标是与 AD 通信，从中提取对象（如域、用户和组等），并以可用格式存储到位于 LDAP 服务器上的专用目录中。 16 | 17 | 我们可以这样比喻：AD 是世界上最庞大的图书馆，而您想要找一本书名提到丧尸的书。这本书是否在美国出版、是否超过 1000 页，或是否为丧尸末日逃生指南，对于 LDAP 而言都无关紧要——尽管它们确实有助于缩小目标的范围。LDAP 是经验丰富的图书管理员，它知道哪里可以找到满足您要求的所有选项，并且会验证您是否已找到要找的目标。 18 | 19 | ## LDAP 身份验证流程 20 | 21 | LDAP 检索是如何发起的？它是如何工作的？ 22 | 23 | LDAP 身份验证使用的是一种客户端加服务器型身份验证模式，包含以下几个重要组成部分： 24 | 25 | - **目录系统代理（DSA）：**作为服务器，在其网络中运行 LDAP 26 | - **目录用户代理（DUA）：**作为客户端（例如，用户的个人电脑），访问 DSA 27 | - **DN：**即专有名称（Distinguished Name），包含了供 LDAP 检索的目录信息树（DIT）的路径（例如，cn=Susan、ou=users、o=Company） 28 | - **相对专有名称（RDN）：**专有名称路径中的各个组成部分（例如，cn=Susan） 29 | - [**应用编程接口**](https://www.redhat.com/zh/topics/api/what-are-application-programming-interfaces)**（API）：**通过 API，您无需了解实施原理，也能将您的产品或服务与其他其他产品或服务互通。 30 | 31 | 当用户尝试访问支持 LDAP 的客户端程序，例如其个人电脑上的商务电子邮件应用，整个 LDAP 流程就开始了。使用 LDAPv3 时，有两种用户身份验证方法：简单身份验证（例如，使用登录凭据的 SSO）和 SASL 身份验证（将 LDAP 服务器绑定到 Kerberos 等程序）。用户尝试登录时，系统会发送一个请求来鉴定分配给用户的 DN。DN 是通过启动 DSA 的客户端 API 或服务器发送的。 32 | 33 | 客户端会自动绑定到 DSA，LDAP 使用 DN 来搜索与 LDAP 数据库中记录相匹配的对象或对象集合。DN 中的 RDN 在这个阶段非常重要，因为它们会一步一步引导 LDAP 搜索 DIT，以找到所需个体。如果路径在后端缺少连接的 RDN，结果可能会呈现为无效。在本例中，LDAP 搜索的对象是个人用户帐户（cn=Susan），它只有在目录中的帐户有匹配的 uid 和 userPassword 时才会验证用户。用户组在 LDAP 目录中也被看做是对象。 34 | 35 | 一旦用户收到回复（无论有效或无效），客户端会从 LDAP 服务器解绑。然后，通过验证的用户可以访问 API 及其服务，包括所需的文件、用户信息和其他应用数据，具体取决于系统管理员授予的权限。 36 | 37 | ## 了解 LDAP 组件 38 | 39 | LDAP 采用轻量型结构并且使用了 DIT，因而能快速运行 LDAP 搜索并提供搜索结果。想要顺利浏览 LDAP 服务器并理解 LDAP 搜索的工作原理，了解 DIT 至关重要。 40 | 41 | DIT 能够让用户快速浏览不同层级的 LDAP 目录，以缩小搜索结果范围并提供对查询的回复。DIT 以根目录开头，后跟国家或地区，然后划分为两个子类：域名（dc）和组织名称（o）。 42 | 43 | **域名（dc）** 44 | 45 | dc（例如，dc=com、dc=example）使用域名系统（DNS）映射来查找互联网域名并将其转译为 IP 地址。 46 | 47 | 大多数用户不知道他们搜索的个体的域名和/或 IP 地址。这时，LDAP 使用分配给用户的专有名称（DN）作为路径，以快速浏览 DIT 并找到搜索结果。接下来就要使用 o 子类了。 48 | 49 | **组织名称（o）** 50 | 51 | o 子类（例如，o-Company）是 DN 中列出的最常用子类之一，通常也是 LDAP 运行搜索时的起始位置。例如，一个简单路径通常以 o 子类开头，分叉到组织单元/部门（ou），后跟用户帐户或组。 52 | 53 | **组织单元（ou）** 54 | 55 | 如前文所述，ou 是 o 的一个子类，通常表现为 ou=users 或 ou=group，分别包含用户帐户或组的列表。其在目录中可能如下所示： 56 | 57 | - o-Company 58 | - ou=groups 59 | - cn=developers 60 | - ou=users 61 | - cn=Susan 62 | 63 | **通用名称（cn）** 64 | 65 | 通用名称或 cn 用于标识组或个人用户帐户的名称（如 cn=developers、cn=Susan）。用户可以从属于某个组；因此，如果 Susan 是开发人员，则也可能会存在于 cn=developers 下。 66 | 67 | **属性和值** 68 | 69 | LDAP DIT 中的各个子类（即 o、ou、cn）包含属性或值，或含有 LDAP 目录相关信息的模式，它们有助于缩小搜索范围。属性有点像地址簿中的条目，有着名称、电话号码和地址等标签，每个属性分配有相应的值。例如，Susan 可能是 name 属性的值。 70 | 71 | 在 cn=Susan 帐户中，user id（uid）和 userPassword 是属性，而用户的登录凭据则是值。不过，在诸如 cn=developers 之类的组中，Susan 可能有 uniqueMember 属性（例如，uniqueMember=cn-Susan,ou-Users,o-Company）。这会将路径映射到 Susan 的个人用户帐户所处的位置，以及 LDAP 所搜索的信息。用户帐户是 DIT 中的末端，也是 LDAP 最终提取搜索结果的地方。 72 | 73 | 还有许多其他属性类型和语法可以帮助缩小搜索范围，包括 organizationalPerson（structural）或 personal（structural）等 ObjectClass。不过，为了保持轻量和易用，LDAP 中的属性数量是有限的。 74 | 75 | ## 为什么要选择 LDAP？ 76 | 77 | 企业网络管理员通常要同时管理成千上万的用户。这意味着，他们要根据用户的角色以及对日常任务所需文件（例如，访问公司内网）的访问权限来分配访问控制和策略。 78 | 79 | LDAP 可以简化用户管理过程，节省网络管理员的宝贵时间，并使身份验证过程集中到同一个地方。在您采用 LDAP 之前，务必要思考以下几个问题： 80 | 81 | - **容量：**您需要存储的用户管理数据有多少？要考虑实施 LDAP 解决方案的产品是否有足够容量来存储和管理您需要的所有数据。 82 | - **搜索频率：**是不是有用户每天都需要访问的数据，如公司内网、电子邮件应用或服务？如果有，那么 LDAP 应该就很适合您。 83 | - **条理性：**LDAP 中的简单 DIT 能否为您的数据提供足够的整理功能，还是说您需要更加细致周到的系统？ 84 | 85 | 虽然 LDAP 通常在 AD 中使用，但也可用于为其他工具和客户端环境提供用户身份验证，例如 Unix 上的红帽目录服务器以及 OpenLDAP（Windows 上的一款开源应用）。您还可以将 LDAP 的身份验证和用户管理功能用于 [API 管理](https://www.redhat.com/zh/topics/api/what-is-api-management)、[基于角色的访问控制](https://www.redhat.com/zh/topics/containers/what-kubernetes-role-based-access-control-rbac)（RBAC），或者 [Docker ](https://www.redhat.com/zh/topics/containers/what-is-docker)和 [Kubernetes](https://www.redhat.com/zh/topics/containers/what-is-kubernetes) 等其他应用和服务。 86 | -------------------------------------------------------------------------------- /OAuth/深入理解现代身份认证与授权：ID Token、Access Token、OAuth 和 OIDC.md: -------------------------------------------------------------------------------- 1 | > DocId: MJ99gVsoRlqlsTKICGRH 2 | 3 | # 深入理解现代身份认证与授权：ID Token、Access Token、OAuth 和 OIDC 4 | 5 | 在当今复杂的网络环境中，安全的身份认证和授权机制对于保护用户数据和系统资源至关重要。本文将深入探讨四个核心概念：ID Token、Access Token、OAuth 2.0 和 OpenID Connect (OIDC)，解析它们的特点、优势以及在现代应用中的角色。 6 | 7 | ## ID Token 与 Access Token：双剑合璧 8 | 9 | ### ID Token 的特点与优势 10 | 11 | 1. **身份验证**：ID Token 主要用于身份验证（Authentication），包含用户的身份信息。 12 | 2. **轻量级**：通常采用 JWT (JSON Web Token) 格式，易于在客户端解析和使用。 13 | 3. **安全性**：可以包含签名，确保信息的完整性和来源可信。 14 | 4. **自包含**：包含了用户的基本信息，减少了额外的用户信息请求。 15 | 16 | ### Access Token 的特点与优势 17 | 18 | 1. **授权**：Access Token 主要用于授权（Authorization），决定用户可以访问哪些资源。 19 | 2. **细粒度控制**：可以为不同的资源或 API 端点分配不同的权限。 20 | 3. **可撤销**：服务器可以随时撤销 Access Token，提高安全性。 21 | 4. **有限寿命**：通常设置较短的有效期，降低被盗用的风险。 22 | 23 | ### 为什么需要同时使用 ID Token 和 Access Token？ 24 | 25 | 1. **职责分离**： 26 | 27 | - ID Token 负责身份验证，回答"用户是谁"的问题。 28 | - Access Token 负责授权，回答"用户可以做什么"的问题。 29 | 30 | 2. **安全性提升**：分离身份验证和授权可以提高系统的安全性。 31 | 32 | 3. **灵活性**：可以根据不同的场景使用不同的令牌。 33 | 34 | 4. **符合标准**：这种分离符合 OAuth 2.0 和 OpenID Connect 等广泛使用的标准。 35 | 36 | 5. **性能优化**： 37 | - ID Token 可以在客户端解析，减少对身份提供者的请求。 38 | - Access Token 可以由资源服务器直接验证，无需每次都查询身份提供者。 39 | 40 | ### 实际形式和使用场景 41 | 42 | #### ID Token 示例 43 | 44 | ``` 45 | 46 | eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiZW1haWwiOiJqb2huQGV4YW1wbGUuY29tIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c 47 | 48 | ``` 49 | 50 | 解码后的 payload： 51 | 52 | ```json 53 | { 54 | "sub": "1234567890", 55 | "name": "John Doe", 56 | "email": "john@example.com", 57 | "iat": 1516239022 58 | } 59 | ``` 60 | 61 | 使用场景： 62 | 63 | - 单页应用（SPA）登录 64 | - 跨域身份验证 65 | 66 | #### Access Token 示例 67 | 68 | 1. 不透明字符串（常见于 OAuth 2.0）： 69 | 70 | ``` 71 | 2YotnFZFEjr1zCsicMWpAA 72 | ``` 73 | 74 | 2. JWT 形式： 75 | ``` 76 | eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwic2NvcGUiOiJyZWFkIHdyaXRlIiwiZXhwIjoxNTE2MjM5MDIyfQ.mRzAjbJGYfMRYEQNgwZ3GbLmOdTnAZKEKXPGXALEHQM 77 | ``` 78 | 79 | 使用场景： 80 | 81 | - API 访问 82 | - 微服务间通信 83 | - 第三方应用授权 84 | 85 | ### 实际使用案例 86 | 87 | 假设有一个名为 "SuperApp" 的应用，使用 Google 登录并访问 Google Drive API： 88 | 89 | ```javascript 90 | // 使用 ID Token 获取用户信息 91 | const idToken = "eyJhbGciOiJIUzI1NiIs..."; 92 | const decodedIdToken = decodeJWT(idToken); 93 | console.log(`Welcome, ${decodedIdToken.name}!`); 94 | 95 | // 使用 Access Token 访问 Google Drive API 96 | const accessToken = "2YotnFZFEjr1zCsicMWpAA"; 97 | fetch("https://www.googleapis.com/drive/v3/files", { 98 | headers: { 99 | Authorization: `Bearer ${accessToken}`, 100 | }, 101 | }) 102 | .then((response) => response.json()) 103 | .then((data) => console.log(data)); 104 | ``` 105 | 106 | ## OAuth 2.0 与 OIDC：授权与身份验证的标准 107 | 108 | ### OAuth 2.0 109 | 110 | OAuth 2.0 是一个授权框架，主要用于允许第三方应用访问用户在某个服务上的资源，而无需知道用户的凭证。 111 | 112 | #### 主要特点： 113 | 114 | 1. **授权**：专注于确定"用户允许应用程序做什么"。 115 | 2. **访问委托**：允许用户授权一个应用访问他们在另一个应用中的数据。 116 | 3. **令牌**：使用访问令牌（Access Token）来授予权限。 117 | 4. **范围**：可以指定访问的范围（scope），限制应用程序的访问权限。 118 | 119 | #### 使用场景： 120 | 121 | - 允许用户授权第三方应用访问他们的 Google Drive 文件。 122 | - 使用 Facebook 账号登录第三方应用，并允许该应用发布状态更新。 123 | 124 | ### OIDC (OpenID Connect) 125 | 126 | OIDC 是建立在 OAuth 2.0 之上的身份层，主要用于身份验证。 127 | 128 | #### 主要特点： 129 | 130 | 1. **身份验证**：专注于验证用户的身份，即确定"用户是谁"。 131 | 2. **ID Token**：引入了 ID Token 的概念，这是一个包含用户身份信息的 JWT。 132 | 3. **标准化的用户信息**：定义了一组标准的用户属性（如姓名、邮箱等）。 133 | 4. **发现**：提供了服务发现机制，允许客户端动态获取 OIDC 提供者的配置。 134 | 135 | #### 使用场景： 136 | 137 | - 单点登录（SSO）系统。 138 | - 获取用户的基本信息，如电子邮件、姓名等。 139 | 140 | ### OAuth 2.0 与 OIDC 的主要区别 141 | 142 | 1. **目的**： 143 | 144 | - OAuth: 主要用于授权（获取访问权限）。 145 | - OIDC: 主要用于身份验证（验证用户身份）。 146 | 147 | 2. **令牌**： 148 | 149 | - OAuth: 主要使用 Access Token。 150 | - OIDC: 使用 ID Token 和 Access Token。 151 | 152 | 3. **信息范围**： 153 | 154 | - OAuth: 不直接提供用户信息。 155 | - OIDC: 提供标准化的用户身份信息。 156 | 157 | 4. **复杂性**： 158 | 159 | - OAuth: 相对简单，专注于授权流程。 160 | - OIDC: 在 OAuth 基础上增加了身份验证层，稍微复杂一些。 161 | 162 | 5. **使用场景**： 163 | - OAuth: 适用于需要访问用户资源的场景。 164 | - OIDC: 适用于需要验证用户身份的场景。 165 | 166 | ## 结论 167 | 168 | 在现代应用开发中，ID Token、Access Token、OAuth 2.0 和 OIDC 共同构建了一个强大而灵活的身份认证和授权体系。ID Token 和 Access Token 分别处理身份验证和授权，而 OAuth 2.0 和 OIDC 则提供了标准化的框架和协议。 169 | 170 | 理解这些概念的区别和联系，对于开发安全、高效的应用至关重要。通过正确使用这些工具，开发者可以构建出既保护用户隐私和数据安全，又提供流畅用户体验的现代应用。 171 | 172 | 在实际应用中，这些技术通常会结合使用，以满足复杂的身份管理需求。随着技术的不断发展，保持对这些核心概念的深入理解，将有助于应对未来的安全挑战，构建更加安全、可靠的数字生态系统。 173 | -------------------------------------------------------------------------------- /SSO/README.md: -------------------------------------------------------------------------------- 1 | # SSO 2 | 3 | # 框架对比 4 | 5 | | [ Keycloak](https://www.keycloak.org/) | [WSO2 Identity Server](https://wso2.com/identity-and-access-management) | [Gluu](https://www.gluu.org/) | [CAS](https://apereo.github.io/cas/) | [OpenAM](https://github.com/OpenIdentityPlatform/OpenAM/) | [Shibboleth IdP](https://www.shibboleth.net/products/identity-provider/) | | 6 | | -------------------------------------- | ----------------------------------------------------------------------- | --------------------------------------------------------------------- | -------------------------------------------------- | --------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | 7 | | OpenID Connect/OAuth support | yes | yes | yes | yes | yes | **third-party** | 8 | | Multi-factor authentication | yes | yes | yes | yes | yes | yes | 9 | | Admin UI | yes | yes | yes | yes | yes | **no** | 10 | | OpenJDK support | yes | [yes](https://docs.wso2.com/display/IS560/Installation+Prerequisites) | | [yes](https://apereo.github.io/cas/6.0.x/planning/Installation-Requirements.html) | [yes](https://backstage.forgerock.com/knowledge/kb/book/b16240196#openjdk) | [yes](https://wiki.shibboleth.net/confluence/display/IDP30/SystemRequirements) | 11 | | Identity brokering | yes | yes | [yes](https://stackoverflow.com/a/54105614/399105) | | | | 12 | | Middleware | Wildfly, JBOSS | **WSO2 Carbon** | Jetty, Apache HTTPD | any Java app server | any Java app server | Jetty, Tomcat | 13 | | Open source | yes | **Note 1** | yes | yes | yes | yes | 14 | | Commercial support | yes | yes | yes | **third-party** | yes | **third-party** | 15 | | Add federation metadata | **no** | | | | | yes | 16 | | Add metadata from URL | **no** | | | | | yes | 17 | | Installation | easy | | | | | **difficult** | 18 | 19 | # Links 20 | 21 | - https://studygolang.com/articles/11794 22 | - https://github.com/samitpal/simple-sso 23 | - https://mp.weixin.qq.com/s/J6YJls05t2C4OGOqHVijhw 24 | -------------------------------------------------------------------------------- /index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | MicroService-Series 7 | 8 | 9 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 34 | 39 | 41 | 46 | 47 |
48 | 59 | 92 | 93 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | 130 | 132 | 133 | 134 | 135 | 136 | 143 | 144 | 145 | -------------------------------------------------------------------------------- /OAuth/99~参考资料/2022~Sheng~OAuth 2.0 协议.md: -------------------------------------------------------------------------------- 1 | # OAuth2.0 协议 2 | 3 | OAuth 2.0 定义了四种授权方式: 4 | 5 | - 授权码模式（authorization code） 6 | - 简化模式（implicit） 7 | - 密码模式（resource owner password credentials） 8 | - 客户端模式（client credentials） 9 | 10 | ## 1. 授权码模式 11 | 12 | 授权码模式（authorization code）是功能最完整、流程最严密的授权模式。它的特点就是通过客户端的后台服务器，与"服务提供商"的认证服务器进行互动。 13 | 14 | ![oauth2_code_flow](https://thinking-oss.oss-cn-beijing.aliyuncs.com/img/2021/10/202110101141573.png) 15 | 16 | ![image-20210608075752483](https://thinking-oss.oss-cn-beijing.aliyuncs.com/img/202110101055393.png) 17 | 18 | 它的步骤如下： 19 | 20 | ```text 21 | （A）用户访问客户端，后者将前者导向认证服务器，并指定"重定向URI"（redirection URI）redirect_uri。 22 | 23 | （B）用户选择是否给予客户端授权。 24 | 25 | （C）假设用户给予授权，认证服务器将用户导向客户端事先指定的redirect_uri，同时附上一个授权码Code。 26 | 27 | （D）客户端收到授权码，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见。 28 | 29 | （E）认证服务器核对了授权码，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。 30 | ``` 31 | 32 | A 步骤中，客户端申请认证的 URI，包含以下参数： 33 | 34 | - response_type：表示授权类型，必选项，此处的值固定为"code" 35 | - client_id：表示客户端的 ID，必选项 36 | - redirect_uri：表示重定向 URI，可选项 37 | - scope：表示申请的权限范围，可选项 38 | - state：表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值。 39 | 40 | ```http 41 | GET /oauth.sample.com/authorize 42 | ?response_type=code 43 | &client_id=s6BhdRkqt3 44 | &redirect_uri=http%3A%2F%2Fclient.sample.com%2Fsignin-oauth 45 | &scope=sns_login token 46 | &state=xyz 47 | ``` 48 | 49 | C 步骤中，服务器回应客户端的 URI，包含以下参数： 50 | 51 | - code：表示授权码，必选项。该码的有效期应该很短，通常设为 10 分钟，客户端只能使用该码一次，否则会被授权服务器拒绝。该码与客户端 ID 和重定向 URI，是一一对应关系。 52 | - state：如果客户端的请求中包含这个参数，认证服务器的回应也必须一模一样包含这个参数。 53 | 54 | ```http 55 | HTTP/1.1 302 Found 56 | Location: https://client.example.com/signin-oauth 57 | ?code=SplxlOBeZQQYbYS6WxSbIA 58 | &state=xyz 59 | ``` 60 | 61 | D 步骤中，客户端向认证服务器申请令牌的 HTTP 请求，包含以下参数： 62 | 63 | - grant_type：表示使用的授权模式，必选项，此处的值固定为"authorization_code"。 64 | - code：表示上一步获得的授权码，必选项。 65 | - redirect_uri：表示重定向 URI，必选项，且必须与 A 步骤中的该参数值保持一致。 66 | - client_id：表示客户端 ID，必选项。 67 | 68 | ```http 69 | POST /token HTTP/1.1 70 | Host: oauth.example.com 71 | Content-Type: application/x-www-form-urlencoded 72 | 73 | grant_type=authorization_code 74 | &code=SplxlOBeZQQYbYS6WxSbIA 75 | &redirect_uri=http%3A%2F%2Fclient.sample.com%2Fsignin-oauth 76 | &client_id=s6BhdRkqt3 77 | ``` 78 | 79 | E 步骤中，认证服务器发送的 HTTP 回复，包含以下参数： 80 | 81 | - access_token：表示访问令牌，必选项。 82 | - token_type：表示令牌类型，该值大小写不敏感，必选项，可以是 bearer 类型或 mac 类型。 83 | - expires_in：表示过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间。 84 | - refresh_token：表示更新令牌，用来获取下一次的访问令牌，可选项。 85 | - scope：表示权限范围，如果与客户端申请的范围一致，此项可省略。 86 | 87 | ```http 88 | HTTP/1.1 200 OK 89 | Content-Type: application/json;charset=UTF-8 90 | Cache-Control: no-store 91 | Pragma: no-cache 92 | 93 | { 94 | "access_token":"2YotnFZFEjr1zCsicMWpAA", 95 | "token_type":"bearer", 96 | "expires_in":3600, 97 | "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA" 98 | } 99 | ``` 100 | 101 | ## 2. 简化模式 102 | 103 | 简化模式（implicit grant type）不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了"授权码"这个步骤，因此得名。所有步骤在浏览器中完成，令牌对访问者是可见的，且客户端不需要认证。 104 | 105 | ![image-20210608100435439](https://thinking-oss.oss-cn-beijing.aliyuncs.com/img/2021/10/202110101100302.png) 106 | 107 | ```text 108 | （A）客户端将用户导向认证服务器。 109 | 110 | （B）用户决定是否给于客户端授权。 111 | 112 | （C）假设用户给予授权，认证服务器向浏览器回应重定向，并在URI的Hash部分包含了访问令牌，将客户端导向“重定向URI”。 113 | 114 | （D）浏览器向资源服务器的“重定向URI”地址发出请求，其中不包括上一步收到的Hash值。 115 | ``` 116 | 117 | A 步骤中，客户端发出的 HTTP 请求，包含以下参数： 118 | 119 | - response_type：表示授权类型，此处的值固定为"token"，必选项。 120 | - client_id：表示客户端的 ID，必选项。 121 | - redirect_uri：表示重定向的 URI，可选项。 122 | - scope：表示权限范围，可选项。 123 | - state：表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值。 124 | 125 | ```http 126 | GET /oauth.sample.com/authorize 127 | ?response_type=token 128 | &client_id=s6BhdRkqt3 129 | &redirect_uri=http%3A%2F%2Fclient.sample.com%2Fcallback 130 | &scope=token 131 | &state=xyz 132 | ``` 133 | 134 | C 步骤中，服务器回应客户端的 URI，包含以下参数： 135 | 136 | - access_token：表示访问令牌，必选项。 137 | - token_type：表示令牌类型，该值大小写不敏感，必选项。 138 | - expires_in：表示过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间。 139 | - scope：表示权限范围，如果与客户端申请的范围一致，此项可省略。 140 | - state：如果客户端的请求中包含这个参数，认证服务器的回应也必须一模一样包含这个参数。 141 | 142 | ```http 143 | HTTP/1.1 302 Found 144 | Location: http://client.sample.com/callback#access_token=2YotnFZFEjr1zCsicMWpAA 145 | &token_type=bearer 146 | &expires_in=3600 147 | &scope=token 148 | &state=xyz 149 | ``` 150 | 151 | 在这个网址的 Hash 部分包含了令牌。 152 | 153 | 根据上面的 D 步骤，下一步浏览器会访问 Location 指定的网址，但是 Hash 部分不会发送。 154 | 155 | ## 3. 密码模式 156 | 157 | 密码模式（Resource Owner Password Credentials Grant）中，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向"服务商提供商"索要授权。 158 | 159 | 在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下，比如客户端是操作系统的一部分。而认证服务器只有在其他授权模式无法执行的情况下，才能考虑使用这种模式。 160 | 161 | 它的步骤如下： 162 | 163 | ```text 164 | （A）用户向客户端提供用户名和密码。 165 | 166 | （B）客户端将用户名和密码发给认证服务器，向后者请求令牌。 167 | 168 | （C）认证服务器确认无误后，向客户端提供访问令牌。 169 | ``` 170 | 171 | B 步骤中，客户端发出的 HTTP 请求，包含以下参数： 172 | 173 | - grant_type：表示授权类型，此处的值固定为"password"，必选项。 174 | - username：表示用户名，必选项。 175 | - password：表示用户的密码，必选项。 176 | - scope：表示权限范围，可选项。 177 | 178 | 下面是一个例子。 179 | 180 | ```http 181 | POST /token HTTP/1.1 182 | Host: oauth.example.com 183 | Content-Type: application/x-www-form-urlencoded 184 | 185 | grant_type=password&username=johndoe&password=A3ddj3w 186 | ``` 187 | 188 | ## 4. 客户端模式 189 | 190 | 客户端模式（Client Credentials Grant）指客户端以自己的名义，而不是以用户的名义，向"服务提供商"进行认证。严格地说，客户端模式并不属于 OAuth 框架所要解决的问题。在这种模式中，用户直接向客户端注册，客户端以自己的名义要求"服务提供商"提供服务，其实不存在授权问题。 191 | 192 | ```text 193 | （A）客户端向认证服务器进行身份认证，并要求一个访问令牌。 194 | 195 | （B）认证服务器确认无误后，向客户端提供访问令牌。 196 | ``` 197 | 198 | A 步骤中，客户端发出的 HTTP 请求，包含以下参数： 199 | 200 | - grant*type：表示授权类型，此处的值固定为"client*credentials"，必选项。 201 | - scope：表示权限范围，可选项。 202 | 203 | ```http 204 | POST /token HTTP/1.1 205 | Host: server.example.com 206 | Content-Type: application/x-www-form-urlencoded 207 | 208 | grant_type=client_credentials 209 | ``` 210 | 211 | ## [#](https://thinking.renzhansheng.cn/pages/7459f3/#_5-更新令牌)5. 更新令牌 212 | 213 | 如果用户访问的时候，客户端的"访问令牌"已经过期，则需要使用"更新令牌"申请一个新的访问令牌。 214 | 215 | 客户端发出更新令牌的 HTTP 请求，包含以下参数： 216 | 217 | - grant*type：表示使用的授权模式，此处的值固定为"refresh*token"，必选项。 218 | - refresh_token：表示早前收到的更新令牌，必选项。 219 | - scope：表示申请的授权范围，不可以超出上一次申请的范围，如果省略该参数，则表示与上一次一致。 220 | 221 | ```http 222 | POST /token HTTP/1.1 223 | Host: oauth.example.com 224 | Content-Type: application/x-www-form-urlencoded 225 | 226 | grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA 227 | ``` 228 | -------------------------------------------------------------------------------- /_sidebar.md: -------------------------------------------------------------------------------- 1 | - 1 01~服务化架构 [5] 2 | - [1.1 01~架构变迁 [4]](/01~服务化架构/01~架构变迁/README.md) 3 | - [1.1.1 SOA](/01~服务化架构/01~架构变迁/SOA.md) 4 | - [1.1.2 云原生](/01~服务化架构/01~架构变迁/云原生.md) 5 | - [1.1.3 单体架构](/01~服务化架构/01~架构变迁/单体架构.md) 6 | - 1.1.4 微服务 [2] 7 | - [1.1.4.1 单体架构到分布式应用](/01~服务化架构/01~架构变迁/微服务/单体架构到分布式应用.md) 8 | - [1.1.4.2 微服务](/01~服务化架构/01~架构变迁/微服务/微服务.md) 9 | - [1.2 02~服务基础 [3]](/01~服务化架构/02~服务基础/README.md) 10 | - [1.2.1 中间件](/01~服务化架构/02~服务基础/中间件.md) 11 | - [1.2.2 服务视图](/01~服务化架构/02~服务基础/服务视图.md) 12 | - [1.2.3 服务间通信](/01~服务化架构/02~服务基础/服务间通信.md) 13 | - [1.3 03~微服务治理 [3]](/01~服务化架构/03~微服务治理/README.md) 14 | - [1.3.1 OpenSergo 规范](/01~服务化架构/03~微服务治理/OpenSergo%20规范/README.md) 15 | 16 | - [1.3.2 分布式应用治理](/01~服务化架构/03~微服务治理/分布式应用治理.md) 17 | - [1.3.3 微服务设计模式](/01~服务化架构/03~微服务治理/微服务设计模式.md) 18 | - [1.4 04~云原生 [4]](/01~服务化架构/04~云原生/README.md) 19 | - [1.4.1 Factor 应用原则](/01~服务化架构/04~云原生/12-Factor%20应用原则.md) 20 | - 1.4.2 99~参考资料 [2] 21 | - [1.4.2.1 一文简述：云原生架构的四个特征六个原则](/01~服务化架构/04~云原生/99~参考资料/2022-一文简述：云原生架构的四个特征六个原则.md) 22 | - [1.4.2.2 容器、K8s、微服务、云原生](/01~服务化架构/04~云原生/99~参考资料/容器、K8s、微服务、云原生.md) 23 | - [1.4.3 Distributionless](/01~服务化架构/04~云原生/Distributionless.md) 24 | - [1.4.4 Serverless [3]](/01~服务化架构/04~云原生/Serverless/README.md) 25 | - [1.4.4.1 BaaS](/01~服务化架构/04~云原生/Serverless/BaaS.md) 26 | - [1.4.4.2 FaaS](/01~服务化架构/04~云原生/Serverless/FaaS.md) 27 | - [1.4.4.3 Serverless 发展历程](/01~服务化架构/04~云原生/Serverless/Serverless%20发展历程.md) 28 | - [1.5 99~参考资料](/01~服务化架构/99~参考资料/README.md) 29 | 30 | - 2 02~微服务 RPC [6] 31 | - 2.1 00~框架对比 [1] 32 | - [2.1.1 微服务框架比较](/02~微服务%20RPC/00~框架对比/微服务框架比较.md) 33 | - [2.2 01~RPC 基础 [6]](/02~微服务%20RPC/01~RPC%20基础/README.md) 34 | - [2.2.1 RPC 安全性](/02~微服务%20RPC/01~RPC%20基础/RPC%20安全性.md) 35 | - [2.2.2 RPC 应用](/02~微服务%20RPC/01~RPC%20基础/RPC%20应用.md) 36 | - [2.2.3 RPC 简史](/02~微服务%20RPC/01~RPC%20基础/RPC%20简史.md) 37 | - [2.2.4 性能对比](/02~微服务%20RPC/01~RPC%20基础/性能对比.md) 38 | - [2.2.5 服务发现](/02~微服务%20RPC/01~RPC%20基础/服务发现/README.md) 39 | 40 | - [2.2.6 服务调用](/02~微服务%20RPC/01~RPC%20基础/服务调用/README.md) 41 | 42 | - 2.3 02~序列化协议 [1] 43 | - [2.3.1 Protobuf](/02~微服务%20RPC/02~序列化协议/Protobuf/README.md) 44 | 45 | - 2.4 03~RPC 框架 [5] 46 | - [2.4.1 Dapr [4]](/02~微服务%20RPC/03~RPC%20框架/Dapr/README.md) 47 | - [2.4.1.1 Components](/02~微服务%20RPC/03~RPC%20框架/Dapr/Components/README.md) 48 | 49 | - 2.4.1.2 应用开发 [4] 50 | - [2.4.1.2.1 Actor [1]](/02~微服务%20RPC/03~RPC%20框架/Dapr/应用开发/Actor/README.md) 51 | - [2.4.1.2.1.1 注册与调用](/02~微服务%20RPC/03~RPC%20框架/Dapr/应用开发/Actor/注册与调用.md) 52 | - [2.4.1.2.2 PubSub [1]](/02~微服务%20RPC/03~RPC%20框架/Dapr/应用开发/PubSub/README.md) 53 | - [2.4.1.2.2.1 消息发布与订阅](/02~微服务%20RPC/03~RPC%20框架/Dapr/应用开发/PubSub/消息发布与订阅.md) 54 | - [2.4.1.2.3 服务调用](/02~微服务%20RPC/03~RPC%20框架/Dapr/应用开发/服务调用.md) 55 | - [2.4.1.2.4 状态管理](/02~微服务%20RPC/03~RPC%20框架/Dapr/应用开发/状态管理.md) 56 | - [2.4.1.3 生产配置](/02~微服务%20RPC/03~RPC%20框架/Dapr/生产配置/README.md) 57 | 58 | - 2.4.1.4 部署案例 [2] 59 | - [2.4.1.4.1 Hello World](/02~微服务%20RPC/03~RPC%20框架/Dapr/部署案例/Hello%20World.md) 60 | - [2.4.1.4.2 K8s](/02~微服务%20RPC/03~RPC%20框架/Dapr/部署案例/K8s.md) 61 | - [2.4.2 Dubbo [3]](/02~微服务%20RPC/03~RPC%20框架/Dubbo/README.md) 62 | - [2.4.2.1 K8s [1]](/02~微服务%20RPC/03~RPC%20框架/Dubbo/K8s/README.md) 63 | - [2.4.2.1.1 K8s 与 Dubbo](/02~微服务%20RPC/03~RPC%20框架/Dubbo/K8s/K8s%20与%20Dubbo.md) 64 | - [2.4.2.2 架构机制](/02~微服务%20RPC/03~RPC%20框架/Dubbo/架构机制/README.md) 65 | 66 | - [2.4.2.3 踩坑汇总](/02~微服务%20RPC/03~RPC%20框架/Dubbo/踩坑汇总.md) 67 | - 2.4.3 Rpcx [2] 68 | - [2.4.3.1 Go RPC 框架](/02~微服务%20RPC/03~RPC%20框架/Rpcx/Go%20RPC%20框架.md) 69 | - [2.4.3.2 REAMDE](/02~微服务%20RPC/03~RPC%20框架/Rpcx/REAMDE.md) 70 | - [2.4.4 ServiceComb](/02~微服务%20RPC/03~RPC%20框架/ServiceComb/README.md) 71 | 72 | - [2.4.5 gRPC [2]](/02~微服务%20RPC/03~RPC%20框架/gRPC/README.md) 73 | - 2.4.5.1 99~参考资料 [1] 74 | - [2.4.5.1.1 李文周 gRPC 教程](/02~微服务%20RPC/03~RPC%20框架/gRPC/99~参考资料/2019-李文周-gRPC%20教程.md) 75 | - [2.4.5.2 开发环境](/02~微服务%20RPC/03~RPC%20框架/gRPC/开发环境.md) 76 | - 2.5 10~实践案例 [1] 77 | - [2.5.1 爱奇艺微服务标准技术架构实践](/02~微服务%20RPC/10~实践案例/爱奇艺微服务标准技术架构实践.md) 78 | - 2.6 99~参考资料 [2] 79 | - 2.6.1 RPC 服务治理框架实战 [1] 80 | - [2.6.1.1 Java RPC 框架](/02~微服务%20RPC/99~参考资料/2019-RPC%20服务治理框架实战/Java%20RPC%20框架.md) 81 | - [2.6.2 RPC 从零开始](/02~微服务%20RPC/99~参考资料/2020-RPC%20从零开始/README.md) 82 | 83 | - [3 03~微服务模式 [6]](/03~微服务模式/README.md) 84 | - [3.1 N + 1 查询](/03~微服务模式/N%20+%201%20查询/README.md) 85 | 86 | - [3.2 分布式追踪 [3]](/03~微服务模式/分布式追踪/README.md) 87 | - [3.2.1 OpenTelemetry](/03~微服务模式/分布式追踪/OpenTelemetry/README.md) 88 | 89 | - [3.2.2 OpenTracing](/03~微服务模式/分布式追踪/OpenTracing/README.md) 90 | 91 | - 3.2.3 系统设计 [2] 92 | - [3.2.3.1 框架对比](/03~微服务模式/分布式追踪/系统设计/框架对比.md) 93 | - [3.2.3.2 系统设计](/03~微服务模式/分布式追踪/系统设计/系统设计.md) 94 | - [3.3 协议编码 [4]](/03~微服务模式/协议编码/README.md) 95 | - [3.3.1 Avro [2]](/03~微服务模式/协议编码/Avro/README.md) 96 | - [3.3.1.1 Java](/03~微服务模式/协议编码/Avro/Java.md) 97 | - [3.3.1.2 模式演变](/03~微服务模式/协议编码/Avro/模式演变.md) 98 | - [3.3.2 Json [2]](/03~微服务模式/协议编码/Json/README.md) 99 | - [3.3.2.1 JSONSchema](/03~微服务模式/协议编码/Json/JSONSchema.md) 100 | - [3.3.2.2 二进制编码](/03~微服务模式/协议编码/Json/二进制编码.md) 101 | - [3.3.3 Protobuf [2]](/03~微服务模式/协议编码/Protobuf/README.md) 102 | - [3.3.3.1 快速开始](/03~微服务模式/协议编码/Protobuf/快速开始.md) 103 | - [3.3.3.2 类型定义](/03~微服务模式/协议编码/Protobuf/类型定义.md) 104 | - [3.3.4 Thrift](/03~微服务模式/协议编码/Thrift/README.md) 105 | 106 | - [3.4 发布订阅](/03~微服务模式/发布订阅/README.md) 107 | 108 | - [3.5 消息传递 [1]](/03~微服务模式/消息传递/README.md) 109 | - [3.5.1 数据流的类型](/03~微服务模式/消息传递/数据流的类型.md) 110 | - [3.6 消息队列](/03~微服务模式/消息队列/README.md) 111 | 112 | - [4 04~接入网关 [4]](/04~接入网关/README.md) 113 | - [4.1 02~负载均衡 [4]](/04~接入网关/02~负载均衡/README.md) 114 | - [4.1.1 LVS](/04~接入网关/02~负载均衡/LVS/README.md) 115 | 116 | - [4.1.2 Scratch [1]](/04~接入网关/02~负载均衡/Scratch/README.md) 117 | - [4.1.2.1 基于 Go 的简单负载均衡](/04~接入网关/02~负载均衡/Scratch/基于%20Go%20的简单负载均衡.md) 118 | - [4.1.3 分流算法](/04~接入网关/02~负载均衡/分流算法.md) 119 | - [4.1.4 负载分层](/04~接入网关/02~负载均衡/负载分层.md) 120 | - 4.2 04~接入网关 [1] 121 | - 4.2.1 Kong [1] 122 | - [4.2.1.1 Kong](/04~接入网关/04~接入网关/Kong/Kong.md) 123 | - [4.3 05~长连接服务 [3]](/04~接入网关/05~长连接服务/README.md) 124 | - 4.3.1 DeepStream [1] 125 | - [4.3.1.1 DeepStream](/04~接入网关/05~长连接服务/DeepStream/DeepStream.md) 126 | - [4.3.2 WebSocket 网关](/04~接入网关/05~长连接服务/WebSocket%20网关/README.md) 127 | 128 | - [4.3.3 多机房多网络](/04~接入网关/05~长连接服务/多机房多网络.md) 129 | - 4.4 10~实践案例 [4] 130 | - [4.4.1 喜马拉雅 自研网关架构演进过程](/04~接入网关/10~实践案例/2021-喜马拉雅-自研网关架构演进过程.md) 131 | - [4.4.2 爱奇艺 基于 Netty 的长连接网关](/04~接入网关/10~实践案例/2021-爱奇艺-基于%20Netty%20的长连接网关.md) 132 | - [4.4.3 How Tinder Built Their Own API Gateway](/04~接入网关/10~实践案例/2022-How%20Tinder%20Built%20Their%20Own%20API%20Gateway.md) 133 | - [4.4.4 Scratch [2]](/04~接入网关/10~实践案例/Scratch/README.md) 134 | - [4.4.4.1 基于 Netty 与 Webflux 的网关](/04~接入网关/10~实践案例/Scratch/基于%20Netty%20与%20Webflux%20的网关/README.md) 135 | 136 | - [4.4.4.2 网关特性](/04~接入网关/10~实践案例/Scratch/网关特性.md) 137 | - [5 05~服务网格 [6]](/05~服务网格/README.md) 138 | - [5.1 Envoy [1]](/05~服务网格/Envoy/README.md) 139 | - [5.1.1 Kuma](/05~服务网格/Envoy/Kuma/README.md) 140 | 141 | - [5.2 Istio](/05~服务网格/Istio/README.md) 142 | 143 | - [5.3 Linkerd](/05~服务网格/Linkerd/README.md) 144 | 145 | - [5.4 Serverless [3]](/05~服务网格/Serverless/README.md) 146 | - [5.4.1 函数模式](/05~服务网格/Serverless/函数模式.md) 147 | - [5.4.2 设计模式](/05~服务网格/Serverless/设计模式.md) 148 | - [5.4.3 阿里云](/05~服务网格/Serverless/阿里云.md) 149 | - 5.5 可视化 [1] 150 | - [5.5.1 Kiali](/05~服务网格/可视化/Kiali/README.md) 151 | 152 | - 5.6 设计与对比 [4] 153 | - [5.6.1 Sidecar](/05~服务网格/设计与对比/Sidecar.md) 154 | - [5.6.2 应用场景](/05~服务网格/设计与对比/应用场景.md) 155 | - [5.6.3 框架对比](/05~服务网格/设计与对比/框架对比.md) 156 | - [5.6.4 背景分析](/05~服务网格/设计与对比/背景分析.md) 157 | - 6 10~系统案例 [1] 158 | - [6.1 其他案例 [2]](/10~系统案例/其他案例/README.md) 159 | - [6.1.1 System Design Primer [8]](/10~系统案例/其他案例/System%20Design%20Primer/README.md) 160 | - [6.1.1.1 AWS 上设计一个百万用户级别的系统](/10~系统案例/其他案例/System%20Design%20Primer/AWS%20上设计一个百万用户级别的系统.md) 161 | - [6.1.1.2 Mint](/10~系统案例/其他案例/System%20Design%20Primer/Mint.md) 162 | - [6.1.1.3 Twitter 时间线和搜索](/10~系统案例/其他案例/System%20Design%20Primer/Twitter%20时间线和搜索.md) 163 | - [6.1.1.4 按类别分类的 Amazon 销售排名](/10~系统案例/其他案例/System%20Design%20Primer/按类别分类的%20Amazon%20销售排名.md) 164 | - [6.1.1.5 搜索引擎的 KV 存储](/10~系统案例/其他案例/System%20Design%20Primer/搜索引擎的%20KV%20存储.md) 165 | - [6.1.1.6 社交网络设计数据结构](/10~系统案例/其他案例/System%20Design%20Primer/社交网络设计数据结构.md) 166 | - [6.1.1.7 网页爬虫](/10~系统案例/其他案例/System%20Design%20Primer/网页爬虫.md) 167 | - [6.1.1.8 设计 Pastebin.com (或者 Bit.ly)](/10~系统案例/其他案例/System%20Design%20Primer/设计%20Pastebin.com%20(或者%20Bit.ly).md) 168 | - [6.1.2 刚果商城](/10~系统案例/其他案例/刚果商城/README.md) 169 | 170 | - [7 INTRODUCTION](/INTRODUCTION.md) -------------------------------------------------------------------------------- /认证基础/99~参考资料/2023-Password, Session, Cookie, Token, JWT, SSO, OAuth - Authentication Explained.md: -------------------------------------------------------------------------------- 1 | > [原文地址](https://blog.bytebytego.com/p/password-session-cookie-token-jwt) 2 | 3 | # Password, Session, Cookie, Token, JWT, SSO, OAuth - Authentication Explained 4 | 5 | When we use various applications and websites, three essential security steps are continuously at play: 6 | 7 | - Identity 8 | - Authentication 9 | - Authorization 10 | 11 | The diagram below shows where these methods apply in a typical website architecture and their meanings. 12 | 13 | [![img](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fced6562d-3be6-4dd4-a141-fed9e6b02182_1600x1226.png)](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fced6562d-3be6-4dd4-a141-fed9e6b02182_1600x1226.png) 14 | 15 | In this 2-part series, we dive into different authentication methods, including passwords, sessions, cookies, tokens, JWTs (JSON Web Tokens), SSO (Single Sign-On), and OAuth2. We discuss the problems each method solves and how to choose the right authentication method for our needs. 16 | 17 | # Password Authentication 18 | 19 | Password authentication is a fundamental and widely used mechanism for verifying a user's identity on websites and applications. In this method, users enter their unique username and password combination to gain access to protected resources. The entered credentials are checked against stored user information in the system, and if they match, the user is granted access. 20 | 21 | While password authentication is a foundational method for user verification, it has some limitations. Users may forget their passwords, and managing unique usernames and passwords for multiple websites can be challenging. Furthermore, password-based systems can be vulnerable to attacks, such as brute-force or dictionary attacks, if proper security measures aren't in place. 22 | 23 | To address these issues, modern systems often implement additional security measures, such as multi-factor authentication, or use other authentication mechanisms (e.g., session-cookie or token-based authentication) to complement or replace password-based authentication for subsequent access to protected resources. 24 | 25 | In this section, we will cover password-based authentication first to understand its history and how it functions. 26 | 27 | ## HTTP Basic Access Authentication 28 | 29 | HTTP basic access authentication requires a web browser to provide a username and a password when requesting a protected resource. The credentials are encoded using the Base64 algorithm and included in the HTTP header field _Authorization: Basic_. 30 | 31 | Here's how it typically works: 32 | 33 | 1. The client sends a request to access a protected resource on the server. 34 | 2. If the client has not yet provided any authentication credentials, the server responds with a 401 Unauthorized status code and includes the WWW-Authenticate: Basic header to indicate that it requires basic authentication. 35 | 3. The client then prompts the user to enter their username and password, which are combined into a single string in the format username:password. 36 | 4. The combined string is Base64 encoded and included in the "Authorization: Basic" header in the subsequent request to the server, e.g., Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=. 37 | 5. Upon receiving the request, the server decodes the Base64-encoded credentials and separates the username and password. The server then checks the provided credentials against its user database or authentication service. 38 | 6. If the credentials match, the server grants access to the requested resource. If not, the server responds with a 401 Unauthorized status code. 39 | 40 | HTTP Basic Access Authentication has limitations. The username and password, encoded using Base64, can be easily decoded. Most websites use TLS (Transport Layer Security) to encrypt data between the browser and server, improving security. However, users' credentials may still be exposed to interception or man-in-the-middle attacks. 41 | 42 | With HTTP Basic Access Authentication, the browser sends the Authorization header with the necessary credentials for each request to protected resources within the same domain. This provides a smoother user experience, without repeatedly entering the username and password. But, as each website maintains its own usernames and passwords, users may find it difficult to remember their credentials. 43 | 44 | This authentication mechanism is obsolete for modern websites. 45 | 46 | [![img](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F10e83d0a-8fb5-42f6-abeb-a5e8980450c3_1600x1275.png)](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F10e83d0a-8fb5-42f6-abeb-a5e8980450c3_1600x1275.png) 47 | 48 | ## Session-Cookie Authentication 49 | 50 | Session-cookie authentication addresses HTTP basic access authentication's inability to track user login status. A session ID is generated to track the user's status during their visit. This session ID is recorded both server-side and in the client’s cookie, serving as an authentication mechanism. It is called a session-cookie because it is a cookie with the session ID stored inside. Users must still provide their username and password initially, after which the server creates a session for the user's visit. Subsequent requests include the cookie, allowing the server to compare client-side and server-side session IDs. 51 | 52 | Let’s see how it works: 53 | 54 | 1. The client sends a request to access a protected resource on the server. If the client has not yet authenticated, the server responds with a login prompt. The client submits their username and password to the server. 55 | 2. The server verifies the provided credentials against its user database or authentication service. If the credentials match, the server generates a unique session ID and creates a corresponding session in the server-side storage (e.g., server memory, database, or session server). 56 | 3. The server sends the session ID to the client as a cookie, typically with a Set-Cookie header. 57 | 4. The client stores the session cookie. 58 | 5. For subsequent requests, it sends the cookie along with the request headers. 59 | 6. The server checks the session ID in the cookie against the stored session data to authenticate the user. 60 | 7. If validated, the server grants access to the requested resource. When the user logs out or after a predetermined expiration time, the server invalidates the session, and the client deletes the session cookie. 61 | 62 | [![img](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F9b3002be-d4f2-489c-99cd-f789012d76dc_1600x1173.png)](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F9b3002be-d4f2-489c-99cd-f789012d76dc_1600x1173.png) 63 | 64 | # Passwordless Authentication 65 | 66 | We have covered three types of authentication so far: HTTP basic authentication, session-cookie authentication, and token-based authentication. They all require a password. However, there are other ways to prove your identity without a password. 67 | 68 | When it comes to authentication, there are three factors to consider: 69 | 70 | - Knowledge factors: something you know, such as a password 71 | - Ownership factors: something you own, such as a device or phone number 72 | - Inherence factors: something unique to you, such as your biometric features 73 | 74 | Passwords fall under “something you know”. One-Time Passwords (OTP) prove that the user owns a cell phone or a device, while biometric authentication proves "something unique to you". 75 | 76 | ## One-Time Passwords (OTP) 77 | 78 | One-Time Passwords (OTP) are widely used as a more secure method of authentication. Unlike static passwords, which can be reused, OTPs are valid for a limited time, typically a few minutes. This means that even if someone intercepts an OTP, they can’t use it to log in later. Additionally, OTPs require “something you own” as well as “something you know” to log in. This can be a cell phone number or email address that the user has access to, making it harder for hackers to steal. 79 | 80 | However, it's important to note that using SMS as the delivery method for OTPs can be less secure than other methods. This is because SMS messages can be intercepted or redirected by hackers, particularly if the user's phone number has been compromised. In some cases, attackers have been able to hijack phone numbers by convincing the mobile carrier to transfer the number to a new SIM card. Once the attacker has control of the number, they can intercept any OTPs sent via SMS. For this reason, it's recommended to use alternative delivery methods, such as email or mobile apps, whenever possible. 81 | 82 | Here’s how OTPs work in more detail: 83 | 84 | Step 1: The user wants to log in to a website and is asked to enter a username, cell phone number, or email. 85 | 86 | Step 2: The server generates an OTP with an expiration time. 87 | 88 | Step 3: The server sends the OTP to the user’s device via SMS or email. 89 | 90 | Step 4: The user enters the OTP received in the login box. 91 | 92 | Step 5-6: The server compares the generated OTP with the one the user entered. If they match, login is granted. 93 | 94 | [![img](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb27865df-e833-47c8-9340-cba5510a90a0_1600x1069.png)](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb27865df-e833-47c8-9340-cba5510a90a0_1600x1069.png) 95 | 96 | Alternatively, a hardware or software key can be used to generate OTPs for multi-factor authentication (MFA). For example, Google 2FA uses a software key that generates a new OTP every 30 seconds. When logging in, users enter their password and the current OTP displayed on their device. This adds an extra layer of security as hackers would need access to the user’s device to steal the OTP. More on MFA later. 97 | 98 | ## SSO (Single Sign-On) 99 | 100 | Single Sign-On (SSO) is a user authentication method that allows us to access multiple systems or applications with a single set of credentials. SSO streamlines the login process, providing a seamless user experience across various platforms. 101 | 102 | The SSO process mainly relies on a Central Authentication Service (CAS) server. Here's a step-by-step breakdown of the SSO process: 103 | 104 | - When we attempt to log in to an application, such as Gmail, we're redirected to the CAS server. 105 | - The CAS server verifies our login credentials and creates a Ticket Granting Ticket (TGT). This TGT is then stored in a Ticket Granting Cookie (TGC) on our browser, representing our global session. 106 | - CAS generates a Service Ticket (ST) for our visit to Gmail and redirects us back to Gmail with the ST. 107 | - Gmail uses the ST to validate our login with the CAS server. After validation, we can access Gmail. 108 | 109 | When we want to access another application, like YouTube, the process is simplified: 110 | 111 | - Since we already have a TGC from our Gmail login, CAS recognizes our authenticated status. 112 | - CAS generates a new ST for YouTube access, and we can use YouTube without inputting our credentials again. 113 | 114 | This process reduces the need to remember and enter multiple sets of credentials for different applications. 115 | 116 | [![img](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fff52780c-e94e-4d80-a083-7c9cbead8b6f_1600x1473.png)](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fff52780c-e94e-4d80-a083-7c9cbead8b6f_1600x1473.png) 117 | 118 | There are different protocols that facilitate SSO: 119 | 120 | - SAML (Security Assertion Markup Language) is widely used in enterprise applications. SAML communicates authentication and authorization data in an XML format. 121 | - OIDC (OpenID Connect) is popular in consumer applications. OIDC handles authentication through JSON Web Tokens (JWT) and builds on the OAuth 2.0 framework. More on this in the next section. 122 | 123 | For new applications, OIDC is the preferred choice. It supports various client types, including web-based, mobile, and [JavaScript clients](https://openid.net/connect/). 124 | 125 | SSO offers a streamlined and secure authentication method, providing a seamless user experience by requiring only one set of credentials for multiple applications. This approach enhances security through the use of strong, unique passwords and reduced phishing risks. It also minimizes administrative burdens for IT departments. 126 | 127 | ## OAuth 2.0 and OpenID Connect (OIDC) 128 | 129 | While OAuth 2.0 is primarily an authorization framework, it can be used in conjunction with OpenID Connect (OIDC) for authentication purposes. OIDC is an authentication layer built on top of OAuth 2.0, enabling the verification of a user's identity and granting controlled access to protected resources. 130 | 131 | When using "Sign in with Google" or similar features, OAuth 2.0 and OIDC work together to streamline the authentication process. OIDC provides user identity data in the form of a standardized JSON Web Token (JWT). This token contains information about the authenticated user, allowing the third-party application to create a user profile without requiring a separate registration process. 132 | 133 | In this setup, [OAuth 2.0](https://oauth.net/2/) provides "secure delegated access" by issuing short-lived tokens instead of passwords, allowing third-party services to access protected resources with the resource owner's permission. This method enhances security, as the third-party service does not handle or store the user's password directly. 134 | 135 | The diagram below shows how the protocol works in the “Sign in with Google” scenario. 136 | 137 | [![img](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F75a1f3e9-7bad-410a-b059-66ccd6189f6b_1600x998.png)](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F75a1f3e9-7bad-410a-b059-66ccd6189f6b_1600x998.png) 138 | 139 | In the “Sign in with Google” example, OAuth 2.0 defines four roles: 140 | 141 | 1. Resource owner: The end user, who controls access to their personal data. 142 | 2. Resource server: The Google server hosting user profiles as protected resources. It uses access tokens to respond to protected resource requests, ensuring that only authorized services can access the data. 143 | 3. Client: The device (PC or smartphone) making requests on behalf of the resource owner. This device represents the third-party application seeking access to the user's data. 144 | 4. Authorization server: The Google authorization server that issues tokens to clients, managing the secure exchange of tokens between the resource server and the client. 145 | 146 | OAuth 2.0 offers four types of authorization grants to accommodate different situations: 147 | 148 | 1. Authorization code grant: The most complete and versatile mode, suitable for most application types. More details below. 149 | 2. Implicit grant: Designed for applications with only a frontend, such as single-page applications or mobile apps. This is no longer recommended. More details below. 150 | 3. Resource owner password credentials grant: Used when users trust a third-party application with their credentials, such as a trusted mobile app. 151 | 4. Client credentials grant: Suitable for cases without a frontend, like command-line tools or server-to-server communication, where resource owner interaction is not needed. 152 | 153 | The standard provides multiple modes to cater to different application scenarios and requirements, ensuring flexibility and adaptability for diverse situations. 154 | 155 | The authorization code grant is one example worth examining. The specifications for the other three grant types are available in [RFC-6749](https://www.rfc-editor.org/rfc/rfc6749). 156 | 157 | [![img](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fce0b4f94-1fae-4d70-a71e-1f82ef93220c_1600x1257.png)](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fce0b4f94-1fae-4d70-a71e-1f82ef93220c_1600x1257.png) 158 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International 2 | Public License 3 | 4 | By exercising the Licensed Rights (defined below), You accept and agree 5 | to be bound by the terms and conditions of this Creative Commons 6 | Attribution-NonCommercial-ShareAlike 4.0 International Public License 7 | ("Public License"). To the extent this Public License may be 8 | interpreted as a contract, You are granted the Licensed Rights in 9 | consideration of Your acceptance of these terms and conditions, and the 10 | Licensor grants You such rights in consideration of benefits the 11 | Licensor receives from making the Licensed Material available under 12 | these terms and conditions. 13 | 14 | 15 | Section 1 -- Definitions. 16 | 17 | a. Adapted Material means material subject to Copyright and Similar 18 | Rights that is derived from or based upon the Licensed Material 19 | and in which the Licensed Material is translated, altered, 20 | arranged, transformed, or otherwise modified in a manner requiring 21 | permission under the Copyright and Similar Rights held by the 22 | Licensor. For purposes of this Public License, where the Licensed 23 | Material is a musical work, performance, or sound recording, 24 | Adapted Material is always produced where the Licensed Material is 25 | synched in timed relation with a moving image. 26 | 27 | b. Adapter's License means the license You apply to Your Copyright 28 | and Similar Rights in Your contributions to Adapted Material in 29 | accordance with the terms and conditions of this Public License. 30 | 31 | c. BY-NC-SA Compatible License means a license listed at 32 | creativecommons.org/compatiblelicenses, approved by Creative 33 | Commons as essentially the equivalent of this Public License. 34 | 35 | d. Copyright and Similar Rights means copyright and/or similar rights 36 | closely related to copyright including, without limitation, 37 | performance, broadcast, sound recording, and Sui Generis Database 38 | Rights, without regard to how the rights are labeled or 39 | categorized. For purposes of this Public License, the rights 40 | specified in Section 2(b)(1)-(2) are not Copyright and Similar 41 | Rights. 42 | 43 | e. Effective Technological Measures means those measures that, in the 44 | absence of proper authority, may not be circumvented under laws 45 | fulfilling obligations under Article 11 of the WIPO Copyright 46 | Treaty adopted on December 20, 1996, and/or similar international 47 | agreements. 48 | 49 | f. Exceptions and Limitations means fair use, fair dealing, and/or 50 | any other exception or limitation to Copyright and Similar Rights 51 | that applies to Your use of the Licensed Material. 52 | 53 | g. License Elements means the license attributes listed in the name 54 | of a Creative Commons Public License. The License Elements of this 55 | Public License are Attribution, NonCommercial, and ShareAlike. 56 | 57 | h. Licensed Material means the artistic or literary work, database, 58 | or other material to which the Licensor applied this Public 59 | License. 60 | 61 | i. Licensed Rights means the rights granted to You subject to the 62 | terms and conditions of this Public License, which are limited to 63 | all Copyright and Similar Rights that apply to Your use of the 64 | Licensed Material and that the Licensor has authority to license. 65 | 66 | j. Licensor means the individual(s) or entity(ies) granting rights 67 | under this Public License. 68 | 69 | k. NonCommercial means not primarily intended for or directed towards 70 | commercial advantage or monetary compensation. For purposes of 71 | this Public License, the exchange of the Licensed Material for 72 | other material subject to Copyright and Similar Rights by digital 73 | file-sharing or similar means is NonCommercial provided there is 74 | no payment of monetary compensation in connection with the 75 | exchange. 76 | 77 | l. Share means to provide material to the public by any means or 78 | process that requires permission under the Licensed Rights, such 79 | as reproduction, public display, public performance, distribution, 80 | dissemination, communication, or importation, and to make material 81 | available to the public including in ways that members of the 82 | public may access the material from a place and at a time 83 | individually chosen by them. 84 | 85 | m. Sui Generis Database Rights means rights other than copyright 86 | resulting from Directive 96/9/EC of the European Parliament and of 87 | the Council of 11 March 1996 on the legal protection of databases, 88 | as amended and/or succeeded, as well as other essentially 89 | equivalent rights anywhere in the world. 90 | 91 | n. You means the individual or entity exercising the Licensed Rights 92 | under this Public License. Your has a corresponding meaning. 93 | 94 | 95 | Section 2 -- Scope. 96 | 97 | a. License grant. 98 | 99 | 1. Subject to the terms and conditions of this Public License, 100 | the Licensor hereby grants You a worldwide, royalty-free, 101 | non-sublicensable, non-exclusive, irrevocable license to 102 | exercise the Licensed Rights in the Licensed Material to: 103 | 104 | a. reproduce and Share the Licensed Material, in whole or 105 | in part, for NonCommercial purposes only; and 106 | 107 | b. produce, reproduce, and Share Adapted Material for 108 | NonCommercial purposes only. 109 | 110 | 2. Exceptions and Limitations. For the avoidance of doubt, where 111 | Exceptions and Limitations apply to Your use, this Public 112 | License does not apply, and You do not need to comply with 113 | its terms and conditions. 114 | 115 | 3. Term. The term of this Public License is specified in Section 116 | 6(a). 117 | 118 | 4. Media and formats; technical modifications allowed. The 119 | Licensor authorizes You to exercise the Licensed Rights in 120 | all media and formats whether now known or hereafter created, 121 | and to make technical modifications necessary to do so. The 122 | Licensor waives and/or agrees not to assert any right or 123 | authority to forbid You from making technical modifications 124 | necessary to exercise the Licensed Rights, including 125 | technical modifications necessary to circumvent Effective 126 | Technological Measures. For purposes of this Public License, 127 | simply making modifications authorized by this Section 2(a) 128 | (4) never produces Adapted Material. 129 | 130 | 5. Downstream recipients. 131 | 132 | a. Offer from the Licensor -- Licensed Material. Every 133 | recipient of the Licensed Material automatically 134 | receives an offer from the Licensor to exercise the 135 | Licensed Rights under the terms and conditions of this 136 | Public License. 137 | 138 | b. Additional offer from the Licensor -- Adapted Material. 139 | Every recipient of Adapted Material from You 140 | automatically receives an offer from the Licensor to 141 | exercise the Licensed Rights in the Adapted Material 142 | under the conditions of the Adapter's License You apply. 143 | 144 | c. No downstream restrictions. You may not offer or impose 145 | any additional or different terms or conditions on, or 146 | apply any Effective Technological Measures to, the 147 | Licensed Material if doing so restricts exercise of the 148 | Licensed Rights by any recipient of the Licensed 149 | Material. 150 | 151 | 6. No endorsement. Nothing in this Public License constitutes or 152 | may be construed as permission to assert or imply that You 153 | are, or that Your use of the Licensed Material is, connected 154 | with, or sponsored, endorsed, or granted official status by, 155 | the Licensor or others designated to receive attribution as 156 | provided in Section 3(a)(1)(A)(i). 157 | 158 | b. Other rights. 159 | 160 | 1. Moral rights, such as the right of integrity, are not 161 | licensed under this Public License, nor are publicity, 162 | privacy, and/or other similar personality rights; however, to 163 | the extent possible, the Licensor waives and/or agrees not to 164 | assert any such rights held by the Licensor to the limited 165 | extent necessary to allow You to exercise the Licensed 166 | Rights, but not otherwise. 167 | 168 | 2. Patent and trademark rights are not licensed under this 169 | Public License. 170 | 171 | 3. To the extent possible, the Licensor waives any right to 172 | collect royalties from You for the exercise of the Licensed 173 | Rights, whether directly or through a collecting society 174 | under any voluntary or waivable statutory or compulsory 175 | licensing scheme. In all other cases the Licensor expressly 176 | reserves any right to collect such royalties, including when 177 | the Licensed Material is used other than for NonCommercial 178 | purposes. 179 | 180 | 181 | Section 3 -- License Conditions. 182 | 183 | Your exercise of the Licensed Rights is expressly made subject to the 184 | following conditions. 185 | 186 | a. Attribution. 187 | 188 | 1. If You Share the Licensed Material (including in modified 189 | form), You must: 190 | 191 | a. retain the following if it is supplied by the Licensor 192 | with the Licensed Material: 193 | 194 | i. identification of the creator(s) of the Licensed 195 | Material and any others designated to receive 196 | attribution, in any reasonable manner requested by 197 | the Licensor (including by pseudonym if 198 | designated); 199 | 200 | ii. a copyright notice; 201 | 202 | iii. a notice that refers to this Public License; 203 | 204 | iv. a notice that refers to the disclaimer of 205 | warranties; 206 | 207 | v. a URI or hyperlink to the Licensed Material to the 208 | extent reasonably practicable; 209 | 210 | b. indicate if You modified the Licensed Material and 211 | retain an indication of any previous modifications; and 212 | 213 | c. indicate the Licensed Material is licensed under this 214 | Public License, and include the text of, or the URI or 215 | hyperlink to, this Public License. 216 | 217 | 2. You may satisfy the conditions in Section 3(a)(1) in any 218 | reasonable manner based on the medium, means, and context in 219 | which You Share the Licensed Material. For example, it may be 220 | reasonable to satisfy the conditions by providing a URI or 221 | hyperlink to a resource that includes the required 222 | information. 223 | 3. If requested by the Licensor, You must remove any of the 224 | information required by Section 3(a)(1)(A) to the extent 225 | reasonably practicable. 226 | 227 | b. ShareAlike. 228 | 229 | In addition to the conditions in Section 3(a), if You Share 230 | Adapted Material You produce, the following conditions also apply. 231 | 232 | 1. The Adapter's License You apply must be a Creative Commons 233 | license with the same License Elements, this version or 234 | later, or a BY-NC-SA Compatible License. 235 | 236 | 2. You must include the text of, or the URI or hyperlink to, the 237 | Adapter's License You apply. You may satisfy this condition 238 | in any reasonable manner based on the medium, means, and 239 | context in which You Share Adapted Material. 240 | 241 | 3. You may not offer or impose any additional or different terms 242 | or conditions on, or apply any Effective Technological 243 | Measures to, Adapted Material that restrict exercise of the 244 | rights granted under the Adapter's License You apply. 245 | 246 | 247 | Section 4 -- Sui Generis Database Rights. 248 | 249 | Where the Licensed Rights include Sui Generis Database Rights that 250 | apply to Your use of the Licensed Material: 251 | 252 | a. for the avoidance of doubt, Section 2(a)(1) grants You the right 253 | to extract, reuse, reproduce, and Share all or a substantial 254 | portion of the contents of the database for NonCommercial purposes 255 | only; 256 | 257 | b. if You include all or a substantial portion of the database 258 | contents in a database in which You have Sui Generis Database 259 | Rights, then the database in which You have Sui Generis Database 260 | Rights (but not its individual contents) is Adapted Material, 261 | including for purposes of Section 3(b); and 262 | 263 | c. You must comply with the conditions in Section 3(a) if You Share 264 | all or a substantial portion of the contents of the database. 265 | 266 | For the avoidance of doubt, this Section 4 supplements and does not 267 | replace Your obligations under this Public License where the Licensed 268 | Rights include other Copyright and Similar Rights. 269 | 270 | 271 | Section 5 -- Disclaimer of Warranties and Limitation of Liability. 272 | 273 | a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE 274 | EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS 275 | AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF 276 | ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS, 277 | IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION, 278 | WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR 279 | PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS, 280 | ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT 281 | KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT 282 | ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU. 283 | 284 | b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE 285 | TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION, 286 | NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT, 287 | INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES, 288 | COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR 289 | USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN 290 | ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR 291 | DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR 292 | IN PART, THIS LIMITATION MAY NOT APPLY TO YOU. 293 | 294 | c. The disclaimer of warranties and limitation of liability provided 295 | above shall be interpreted in a manner that, to the extent 296 | possible, most closely approximates an absolute disclaimer and 297 | waiver of all liability. 298 | 299 | 300 | Section 6 -- Term and Termination. 301 | 302 | a. This Public License applies for the term of the Copyright and 303 | Similar Rights licensed here. However, if You fail to comply with 304 | this Public License, then Your rights under this Public License 305 | terminate automatically. 306 | 307 | b. Where Your right to use the Licensed Material has terminated under 308 | Section 6(a), it reinstates: 309 | 310 | 1. automatically as of the date the violation is cured, provided 311 | it is cured within 30 days of Your discovery of the 312 | violation; or 313 | 314 | 2. upon express reinstatement by the Licensor. 315 | 316 | For the avoidance of doubt, this Section 6(b) does not affect any 317 | right the Licensor may have to seek remedies for Your violations 318 | of this Public License. 319 | 320 | c. For the avoidance of doubt, the Licensor may also offer the 321 | Licensed Material under separate terms or conditions or stop 322 | distributing the Licensed Material at any time; however, doing so 323 | will not terminate this Public License. 324 | 325 | d. Sections 1, 5, 6, 7, and 8 survive termination of this Public 326 | License. 327 | 328 | 329 | Section 7 -- Other Terms and Conditions. 330 | 331 | a. The Licensor shall not be bound by any additional or different 332 | terms or conditions communicated by You unless expressly agreed. 333 | 334 | b. Any arrangements, understandings, or agreements regarding the 335 | Licensed Material not stated herein are separate from and 336 | independent of the terms and conditions of this Public License. 337 | 338 | 339 | Section 8 -- Interpretation. 340 | 341 | a. For the avoidance of doubt, this Public License does not, and 342 | shall not be interpreted to, reduce, limit, restrict, or impose 343 | conditions on any use of the Licensed Material that could lawfully 344 | be made without permission under this Public License. 345 | 346 | b. To the extent possible, if any provision of this Public License is 347 | deemed unenforceable, it shall be automatically reformed to the 348 | minimum extent necessary to make it enforceable. If the provision 349 | cannot be reformed, it shall be severed from this Public License 350 | without affecting the enforceability of the remaining terms and 351 | conditions. 352 | 353 | c. No term or condition of this Public License will be waived and no 354 | failure to comply consented to unless expressly agreed to by the 355 | Licensor. 356 | 357 | d. Nothing in this Public License constitutes or may be interpreted 358 | as a limitation upon, or waiver of, any privileges and immunities 359 | that apply to the Licensor or You, including from the legal 360 | processes of any jurisdiction or authority. 361 | --------------------------------------------------------------------------------