Nginx（24）-Nginx Plus增强功能之身份验证JWT

已于 2023-12-27 18:30:25 修改
阅读量1.8k 收藏 18
点赞数 22
分类专栏： 精通Nginx 文章标签： nginx 服务器 数据库
于 2023-12-13 08:36:08 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/davidwkx/article/details/134552667
版权

        使用NGINX Plus，可以使用JWT身份验证来控制对资源的访问。JWT 规范是 OpenID Connect 的重要基础，它为 OAuth 2.0 生态系统提供了单点登录令牌。JWT 本身还可以用作身份验证凭证，相比传统 API 密钥，它提供了一种更好的对基于 Web 的 API 的访问控制。API和微服务的部署者也在转向JWT标准，因为它的简单性和灵活性。使用JWT身份验证，客户端提供一个JSON Web令牌，该令牌将根据本地密钥文件或远程服务进行验证。

从session认证说起

       互联网服务基本都离不开用户认证。目前最主流的用户认证就是采用session认证模式。

session基本流程

1、客户端浏览器向服务器发送用户名和密码。

2、服务器验证通过后，在当前对话（session）里面保存相关数据，比如用户角色、登录时间等等。

3、服务器向用户返回一个 session_id，写入用户的 Cookie。

4、用户随后的每一次请求，都会通过 Cookie，将 session_id 传回服务器。

5、服务器收到 session_id，找到前期保存的数据，由此得知用户的身份。

session认证缺点

       session认证模式最大优点就是简单成熟。但存在如下缺点：

  1. 服务端保存每个用户的session，随着认证用户的增多，服务端的开销会明显增大。
  2. session信息保存在当前服务器内存中，意味着用户下次请求还必须要请求在这台服务器上。如果是分布式应用，就相应限制了负载均衡器的能力，也就意味着限制了应用的扩展能力。
  3. 因为后续访问合法性是基于cookie中session_id来进行的，如果cookie被截获，用户就会很容易受到跨站请求伪造的攻击。

session优化方案

        针对分布式应用，session优化方案就是session信息集中缓存到缓存服务器（redis），每次用户访问，从缓存服务器获取session信息验证。这样能解决前述缺点1、2。

        另一类涉及单点登陆，如A和B两个系统是同一家公司的关联系统，要求用户只要在其中一个系统登录，再访问另一个系统就会自动登录。如果上述方案想要解决，还需把用户及权限信息从A、B系统中抽取出来统一化。

        优化方案的另一种思路方案就是服务器不保存 session 数据，所有数据都保存在客户端，客户端每次请求都发回服务器。JWT就是这种方案实现规范。

了解JWT

        JWT（Json Web Token）是一种开放标准协议(RFC7519)，它定义了一种“紧凑”和“自包含”的方式，用于各方之间作为JSON对象安全地传输信息。JWT通常用于在各方之间安全地将信息作为JSON对象进行传输，可以在数据传输过程中对数据进行加密、签名等处理。

        JWT的使用场景包括身份认证和授权，可以在用户登录后将JWT包含在响应中返回给客户端，客户端在后续请求中将JWT放在请求头中，服务器验证JWT的签名和有效性后，根据JWT中的声明信息进行权限验证。

        JWT的优点包括：自包含，可以避免多次数据库查询，提高性能；适用于跨域通信，可以在多个服务之间安全地传输信息；可以通过加密和签名保护数据的安全性和完整性。

        需要注意的是，JWT不是一种加密技术，它不能保护数据的内容，只能保护数据的传输安全性和完整性。同时，由于JWT是基于JSON的，它的大小比较有限制，不适合传输大量数据。

基本原理

        JWT 的原理是服务器认证以后将用户信息生成一个 JWT的Token，发回给客户端保存，后续客户端每次请求服务端只需要使用保存的密钥验证token的正确性，服务端不用再保存任何session数据，降低服务端资源消耗，同时使服务端变得无状态，更便于系统扩展。

JWT结构

        在URL传输中，JWT表现为：AAA.BBB.CCC（从前到后包括用"."隔开的三部分），实际例子如下：

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJBcHAgU3lzdGVtIiwic3ViIjoiQXBwLUFQSS1HYXRld2EiLCJleHRyYSI6InRlc3QifQ.f65pTyWLg2dj77Gj3eKp3eU8tf3H-z7tiSHwD5u-3iI

        JWT三部分分别是：头部（Header）内容、负载（Payload）内容和签名（Signature）内容。

头部

        JWT头部为json格式，包含令牌类型和算法信息，定义如下：

{
    # JWT头类型固定为"JWT"
    "typ":"JWT",
    # 签名算法
    "alg":"HS256"
}

头部字符串就是JSON头部json的Base64url编码。

负载

        负载部分就是要传输json格式的数据，通常是用户相关信息；JWT 规定了7个字段值，分别是：

  • iss (issuer)：jwt签发者，大小写敏感
  • sub (subject)：主题字符串（通常用于区分是哪个应用），必须是在发行人的上下文中是唯一的。大小写敏感
  • aud (audience)：受众，即处理JWT的主体。如果处理JWT的主体不是自己，则JWT必须被拒绝。
  • exp (expiration time)：过期时间，在这个时间之后JWT无效。是一个NumericDate值。
  • nbf (Not Before)：生效时间，在这个时间之前JWT无效。是一个NumericDate值。
  • iat (Issued At)：jwt签发时间。
  • jti (JWT ID)：JWT唯一标识符。标识符值的分配方式必须确保相同值意外分配给不同数据对象的可能性可以忽略不计；如果应用程序使用多个颁发者，则必须防止不同颁发者生成的值之间发生冲突。“jti”声明可以用来防止JWT被重播。“jti”值是一个区分大小写的字符串。

       虽然JWT 规定了7个字段值，但均为可选，实际上负载可为任何数据。如果用于身份验证，优先选用规定的字段值。

        负载字符串就是负载json的Base64url编码。

签名

        签名就是对头部和负载的签名，以保证令牌的完整性。签名用的算法是头部指定("alg")。JWT支持的签名（JWS-JSON Web Signature，相关规范为RFC7515）算法如下：

  • HS256, HS384, HS512
  • RS256, RS384, RS512
  • ES256, ES384, ES512
  • EdDSA(Ed25519 and Ed448 signatures)

JWT使用演示

       用手工生成使用JWT的一个过程。实例中的头部为：

{
  "typ": "JWT",
  "alg": "HS256",
}

  负载为：

{
  "iss": "App System",
  "sub": "App-API-Gatewa",
  # 非标准字段
  "extra": "test"
}

步骤如下：

1、分别对头部和负载进行Base64URL编码

# echo -n '{"typ":"JWT","alg":"HS256"}' | base64 | tr '+/' '-_' | tr -d '='
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
# echo -n '{"iss":"App System","sub":"App-API-Gatewa","extra":"test"}' | base64 | tr '+/' '-_' | tr -d '='
eyJpc3MiOiJBcHAgU3lzdGVtIiwic3ViIjoiQXBwLUFQSS1HYXRld2EiLCJleHRyYSI6InRlc3QifQ

2、签名

# HEADER_PAYLOAD=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJBcHAgU3lzdGVtIiwic3ViIjoiQXBwLUFQSS1HYXRld2EiLCJleHRyYSI6InRlc3QifQ
# echo -n $HEADER_PAYLOAD | openssl dgst -binary -sha256 -hmac fantasticjwt | base64 | tr '+/' '-_' | tr -d '='
f65pTyWLg2dj77Gj3eKp3eU8tf3H-z7tiSHwD5u-3iI

3、形成jwt串并发给客户端

jwt_str=${HEADER_PAYLOAD}.f65pTyWLg2dj77Gj3eKp3eU8tf3H-z7tiSHwD5u-3iI

4、客户端发送到服务器

curl -H "Authorization: Bearer ${jwt_str}" http://localhost/api/apply

curl 命令将 JWT 以 Bearer Token 的形式发送给服务器。根据 JWT 标准，URL使用JWT默认头字段为"Authentication"。

        至此模拟了jwt如何生成并使用，可初步感受到JWT用处。

JWT特点

  1.  JWT 默认是不加密，但也是可以加密的。生成原始 Token 以后，可以用密钥再加密一次。
  2. JWT 不加密的情况下，不建议将敏感数据写入 JWT。
  3. JWT 不仅可以用于认证，也可以用于交换信息。有效使用 JWT，可以降低服务器查询数据库的次数。
  4. JWT 的最大缺点是，由于服务器不保存 session 状态，因此无法在使用过程中废止某个 token，或者更改 token 的权限。也就是说，一旦 JWT 签发了，在到期之前就会始终有效，除非服务器部署额外的逻辑。
  5. JWT 本身包含了认证信息，一旦泄露，任何人都可以获得该令牌的所有权限。为了减少盗用，JWT 的有效期应该设置得比较短。对于一些比较重要的权限，使用时应该再次对用户进行认证。
  6. 为了减少盗用，JWT 不应该使用 HTTP 协议明文传输，要使用 HTTPS 协议传输。

Nginx用JWT身份验证

API认证

       当我们系统同第三方系统对接时，对方系统访问我们系统通常需要身份认证识别，一般解决方案如下：

  1. 为对方分配应用号+key，以及签名方法
  2. 对方编程访问验证接口，返回通讯token
  3. 后续对方每次访问带token，我们系统验证token合法性

       JWT就比较好的能解决这个问题，用Nginx plus作为API访问网关，负责对调用API的第三方进行身份验证，业务API可以不关注身份识别问题，也不对外部提供直接访问，而是通过Nginx plus验证合格后才能访问。系统访问示意如下：

       具体实现步骤如下：

  1. 生成外部系统JWT（可以程序或手工），负载中增加字段”appid"，代表每个外部系统
  2. 发送JWT给外部系统的第三方，第三方开发规范要求是在访问系统API时，必须在头部增加字段：Authentication ，值为JWT。
  3. 外部系统发起访问API，Nginx进行JWT验证，合法就反向代理到内部系统API服务。

Nginx做配置如下：

# 所有外部可访问API都是"/api/"开始的
location /api/ {
    # 开启JWT验证，默认从Authentication头字段取JWT
    auth_jwt "api"; 
    # JWT类型
    auth_jwt_type     encrypted;
    # 验证需要的密钥文件
    auth_jwt_key_file conf/keys.jwk;

    # 反向代理到真实api
    # 从jwt中取出appid，api按此识别不同第三方系统
    proxy_set_header "appid" $jwt_claim_appid
    proxy_pass http://api_server;
}

指令与内置变量

auth_jwt

格式：auth_jwt string [token=$variable] | off; 默认：auth_jwt off;

启用JWT验证。

string：设置验证领域，出错时会返回。参数值可以包含变量。

token：指定一个包含JWT变量。默认情况下，JWT作为承载令牌在“Authorization”标头中传递。JWT也可以作为cookie或查询字符串的一部分传递：

# 从cookie中的auth_token取jwt
auth_jwt "valid access" token=$cookie_auth_token;
# 从查询参数的apijwt取jwt
auth_jwt "valid access" token=$arg_apijwt;

off：取消从以前的配置级别继承的auth_jwt指令的效果。

auth_jwt_key_file

格式：auth_jwt_key_file file;

指定JWK格式(RFC7516)的文件，用于验证JWT签名。文件后缀可以是".jwk"或".json"，但内容需要符合规范。可以指定多个文件，例如：

auth_jwt_key_file conf/keys.json;
auth_jwt_key_file conf/key.jwk;

auth_jwt_key_request 

格式：auth_jwt_key_request uri;

从子请求中uri检索JWK文件以验证JWT签名。参数值可以包含变量。为了避免验证开销，建议缓存密钥文件，示例如下：

proxy_cache_path /data/nginx/cache levels=1 keys_zone=foo:10m;

server {
    ...

    location / {
        auth_jwt             "closed site";
        auth_jwt_key_request /jwks_uri;
    }

    location = /jwks_uri {
        internal;
        # 缓存（后续可自动从缓存获取）
        proxy_cache foo;
        proxy_pass  http://idp.example.com/keys;
    }
}

可以来自多个子请求，如：

auth_jwt_key_request /jwks_uri;
auth_jwt_key_request /jwks2_uri;

auth_jwt_type

格式：auth_jwt_type signed | encrypted | nested; 默认：auth_jwt_type signed;

JWT类型，有三种：signed-只是签名；encrypted-只加密； nested-先签名再加密

auth_jwt_header_set

格式：auth_jwt_header_set $variable name ...;

设置JWT头部变量值。$variable 为对应key

auth_jwt_claim_set

格式：auth_jwt_claim_set $variable name ...;

设置JWT负载部变量值。$variable 为对应key

内部变量-$jwt_header_name

返回JWT头部字段值，name是头部字段key，使用时用实际key名代替name

内部变量-$jwt_claim_name

返回JWT负载部字段值，name是负载字段key，使用时用实际key名代替name

内部变量-$jwt_payload

对于nested类型JWT，返回封闭的JWS Token。对于encrypted类型JWT，返回带有负载的JSON。

JWK 文件

       Nginx plus对JWT要进行加密（JWE-JSON Web Encryption ，规范RFC7516），加密时在JWT头部增加”enc“字段，说明是哪种加密算法，支持的加密算法有：

  • A128CBC-HS256, A192CBC-HS384, A256CBC-HS512
  • A128GCM, A192GCM, A256GCM

       加密必然涉及密钥，NGINX Plus 使用 RFC 标准中指定的 JWK （JSON Web Key）格式。该标准允许在 JWK 文件中包含一个关键对象数组。密钥文件示例如下：

{"keys":[
    {
        # 密码类型
        "kty":"oct",
        # 密钥顺序号
        "kid":"0001",
         # 密码（base64URL编码）
        "k":"OctetSequenceKeyValue"
    },
    {
        "kty":"EC",
        "kid":"0002"
        "crv":"P-256",
        "x": "XCoordinateValue",
        "y": "YCoordinateValue",
        "d": "PrivateExponent",
        "use": "sig"
    },
    {
        "kty":"RSA",
        "kid":"0003"
        "n": "Modulus",
        "e": "Exponent",
        "d": "PrivateExponent"
    }
]}

其中”kty"是密钥类型。该文件显示了三种密钥类型：Octet Sequence （oct）、EllipticCurve（EC）和 RSA 类型。kid 属性是密钥 ID。其它属性可查RFC7517规范文件。

        密钥文件是敏感数据，应注意安全保护。

注销 JWT

       JWT一个缺点就是由于服务器不保存 session 状态，因此无法在使用过程中废止某个 token，或者更改 token 的权限。Nginx plus通过将 API 客户端的 JWT 标记为无效来拒绝该客户端访问，直到 JWT 到期为止（到期时间在 exp 声明中表示），此时该 JWT 的 map 条目可以被安全删除。示例如下：

# 负载部sub值为"quotes"、"test"标记为"revoked"
map $jwt_claim_sub $jwt_status {
    "quotes" "revoked";
    "test"   "revoked";
    default  "";
}

server {
    listen 80;

    location /products/ {
        auth_jwt "Products API";
        auth_jwt_key_file conf/api_secret.jwk;

        # 标记为"revoked"的请求拒绝访问
        if ( $jwt_status = "revoked" ) {
            return 403;
        }

        proxy_pass http://api_server;
    }
}

JWT其它用途

       JWT 验证完成后，NGINX Plus 可以访问标头和有效负载中作为变量的所有字段。这些可以通过将 $jwt_header_ 或 $jwt_claim_ 前缀添加到所需字段（例如 for the sub 声明的 $jwt_claim_sub）来访问。这意味着可以非常轻松地将 JWT 内包含的信息代理到 API 端点，而不需要在 API 本身中实现 JWT 处理。

       以下配置示例灵活运用JWT：

log_format jwt '$remote_addr - $remote_user [$time_local] "$request" '
               '$status $body_bytes_sent "$http_referer" "$http_user_agent" '
               '$jwt_header_alg $jwt_claim_sub';  #用到jwt变量

# 用$jwt_claim_sub作为key定义限制请求缓存区
limit_req_zone $jwt_claim_sub zone=10rps_per_client:1m rate=10r/s;

server {
    listen 80;

    location /API/ {
        auth_jwt "Products API";
        auth_jwt_key_file conf/api_secret.jwk;

        # 限制请求数
        limit_req zone=10rps_per_client;

        proxy_pass http://api_server;
        # 传参给API
        proxy_set_header API-Client $jwt_claim_sub;

        # 记录日志
        access_log /var/log/nginx/access_jwt.log jwt;
    }
}

这篇文章如果对您有所帮助或者启发的话，帮忙关注或点赞，有问题请评论，必有所复。您的支持是我写作的最大动力！

配置nginx身份验证(ngx_http_auth_basic_module)
Bertram的博客
02-22 1428
当我们有某个页面或者目录希望开放给特定用户来看的时候,就需要加上权限验证,这时候有人可能会想到做一套权限系统或者登录系统,但是如果我们仅仅是临时开放,完全没有必要做一套复杂的系统,这时候可是使用nginx自带的ngx_http_auth_basic_module模块,可以非常方便的实现如上的效果. 在对应nginx配置文件中增加如下配置项 location / { auth_basic "closed site"; auth_basic_user_file conf/htpass
使用Nginx进行基本身份验证的方法
IbcVue的博客
09-26 621
通过使用Nginx的基本身份验证功能，你可以在Web站点上实现强制用户认证的功能。通过按照上述步骤安装Nginx，创建密码文件，配置Nginx并重启服务，你可以轻松地为你的Web站点添加基本身份验证。通过使用Nginx的基本身份验证功能，你可以要求用户通过用户名和密码进行认证，然后才能访问你的Web站点。现在，你可以尝试访问你的Web站点。找到Nginx的配置文件，通常位于/etc/nginx/nginx.conf或/etc/nginx/conf.d/default.conf。首先，你需要安装Nginx。
session 共享、Nginx session 共享、Token、Json web Token 【JWT】等认证
u013400314的博客
06-21 350
1、安装 System.IdentityModel.Tokens.Jwt。
Nginx系列-12 Nginx使用Lua脚本进行JWT校验
shengyu
07-28 1430
本文介绍Nginx中Lua模块使用方式，并结合案例进行介绍。案例介绍通过lua脚本提取HTTP请求头中的token字段，经过JWT校验并提取id和name信息，设置到http请求头中发向后段服务器。 默认情况下，Nginx自身不携带lua模块，即不支持通过lua脚本进行功能扩展。需要在编译Nginx时手动引入lua模块，或者直接使用openresty，本文结合后者进行介绍。
深入NGINX Plus：安全认证与JWT验证
最新发布
weixin_36474966的博客
04-23 243
本文将详细介绍NGINX Plus在处理请求时如何进行认证以及如何利用JSON Web Tokens (JWT) 进行安全验证。通过具体配置示例和讨论，我们将探索NGINX Plus的http_auth_request_module、JWT认证模块以及如何生成和管理JSON Web Keys (JWK)。
25.在 Nginx 中设置身份验证
我的博客，不一样的自我表达
05-12 570
🍺当我们使用 Nginx 时，碰巧我们想要限制对某些 URL 和/或端点的访问。因此，为此，我们需要在 Nginx 中设置身份验证，这就是我们今天将要看到的。所以在你的配置文件中，像下面的例子一样添加auth_basic&参数，它应该是好的！所以在你的配置文件中，像下面的例子一样添加auth_basic&参数，它应该是好的！当我们使用 Nginx 时，碰巧我们想要限制对某些 URL 和/或端点的访问。因此，为此，我们需要在 Nginx 中设置身份验证，这就是我们今天将要看到的。使用 htpasswd。
【NGINX--5】身份验证
qq11771258的博客
11-24 2728
NGINX Plus 的 HTTP JWT 身份验证模块支持验证符合 RFC JSON Web Signature 规范的 JWT，允许任何使用 JWT 的 SSO 授权立即在 NGINX Plus 层中进行验证。auth_jwt 指令还可用于从继承的配置中消除所需的 JWT 身份验证的影响。在上面的示例中，子请求的位置被锁定，以确保仅响应内部的 NGINX Plus 请求。如果您的身份验证服务未请求请求正文，则可以使用 proxy_pass_request_body 指令删除请求正文，如上所示。
Complete-NGINX-Cookbook-2019-中文翻译1
08-04
JWT 认证使用 JSON Web Token 来验证用户身份，提供了高安全性的身份验证机制。 高可用性 NGINX Plus 提供了高可用性功能，可以确保应用程序的高可用性。NGINX Plus 可以自动detect 和 recover 故障节点，确保应用...
RuoYi-Vue-Plus 是重写 RuoYi-Vue 针对 分布式集群与多租户 场景全方位升级(不兼容原框架)
06-02
同时，结合 JWT（JSON Web Tokens）进行会话管理，保证了用户身份的安全传输和验证。此外，还可能包含权限控制、API 安全策略等，防止未授权访问和数据泄露。 五、微服务架构 为了适应分布式环境，RuoYi-Vue-Plus ...
NGINX Plus OpenID Connect集成的实现指南
该实现假定使用NGINX Plus组件，NGINX Plus是一种增强了NGINX软件功能的商业版本，提供了更多的高级特性，如负载均衡、健康检查、限流和会话持久性等。 #### 5.2 配置和集成 实现OpenID Connect与NGINX Plus集成...
nginx官方文档中文版
06-13
Nginx 官方文档中文版知识点总结 Nginx 是一个开源的 Web 服务器软件，可以作为 Web ...* 设置 Amazon EC2 的 Nginx Plus 环境 * 使用 DTrace pid 提供程序调试 Nginx * 转换重写规则 * WebSocket 代理 * 开发贡献指南
Java技术栈/面试题合集(10)-Nginx篇-part2
BADAO_LIUMANG_QIZHI的博客
11-11 8401
通常，当Nginx收到一个请求时，它会根据请求中的Host头来匹配server块。如果没有任何server块匹配这个Host，Nginx会默认使用第一个定义的server块来处理请求。这可能不是用户想要的，希望阻止那些未定义Host的请求，比如防止恶意请求或者垃圾流量。利用 default_server 机制和 444 状态码配置。配置默认服务器块通过定义 default_server 的监听端口，捕获所有未匹配任何 server_name 的请求配置示例server {
探索JWT认证新境界：Nginx上的nginx-jwt
gitblog_00804的博客
08-25 758
探索JWT认证新境界：Nginx上的nginx-jwt nginx-jwtLua script for Nginx that performs reverse proxy auth using JWT's项目地址:https://gitcode.com/gh_mirrors/ng/nginx-jwt 随着微服务和RESTful API的日益普及，安全地保护这些服务成为了开发者的一大挑战。ngin...
Nginx-JWT：基于Nginx实现JWT身份验证的开源解决方案
gitblog_01070的博客
08-23 649
Nginx-JWT：基于Nginx实现JWT身份验证的开源解决方案 nginx-jwtLua script for Nginx that performs reverse proxy auth using JWT's项目地址:https://gitcode.com/gh_mirrors/ng/nginx-jwt 项目介绍 Nginx-JWT 是一个旨在为Nginx提供JSON Web Token...
通过配置Nginx来控制静态资源访问的Security(JWT)权限认证
ai_haibin的博客
09-20 2909
NGINX访问静态资源需通过鉴权
Nginx 精通 - Nginx Plus增强功能之身份验证JWT
qq_33240556的博客
03-22 258
通过这些功能，Nginx Plus不仅能够作为高性能的反向代理和负载均衡器，还能作为API Gateway，承担起保护后端服务、验证客户端身份的重要职责，从而提升整个应用程序的安全性和可控性。Nginx Plus可以验证客户端提交的JWT令牌的有效性，包括检查签名、过期时间、受众（audience）和发行人（issuer）等属性。可以将JWT中的claim映射到Nginx变量，这样可以利用这些变量来进行更复杂的访问控制决策，比如基于角色的访问控制（RBAC）。
企业级实战——畅购商城SpringCloud-微服务网关鉴权&限流解决方案-JWT+nginx——商品添加-规格查询分析
aming小老弟
10-16 393
QQ 1274510382 Wechat JNZ_aming 商业联盟 QQ群538250800 技术搞事 QQ群599020441 解决方案 QQ群152889761 加入我们 QQ群649347320 共享学习 QQ群674240731 纪年科技aming 网络安全 ,深度学习,嵌入式,机器强化,生物智能,生命科学。 纸上得来终觉浅,绝知此事要躬行 ！！！寻找志同道合伙伴抱团创业中。。。 ...
nginx用户验证
weixin_33711647的博客
08-17 194
2019独角兽企业重金招聘Python工程师标准>>> ...
4.3.6、基于Nginx身份验证代理
enumlin
08-24 1831
基于Nginx身份验证代理 通过这个方法，你可以实现在你的registry前面增加一层基本的身份校验功能的方向代理。 这种模型赋予你使用任意的身份验证后端的能力，你需要通过一个二次验证的机制去实现它们，在你的代理内部。而且要求把TLS终端从registry端迁到它的内部。 此外，在你的通信链路中添加了额外的http层，增加了部署、维护、调试的复杂度，可能还会引入一些信息的问题(比
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

乐享技术

每一个打赏，都是对我最大的鼓励

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值