api postmain 鉴权_API网关为什么要统一认证/鉴权？

首先要明白你出于什么场景要用API网关。

1、业务诉求：一般情况下是因为后端服务太多太多，API网关可以给用户提供一个统一的Endpoint，用户不用记那么多乱七八糟的内部服务访问点。这种情况下，实际诉求是业务诉求。

请求归一了，风险也归一了，在安全上的好处：减少攻击面：如果后端服务都暴露接口，那么攻击者看到的是10个入口，API网关就只有1个入口，防1个好过防10个。

集中优势资源：API网关此时处于Hish Risk，可以集中后台10个服务的安全资源加固API网关，可以做的更充分。

纵深防御：这种场景下API网关有认证/鉴权，一般内部服务仍旧有认证/鉴权。攻击者攻破API网关后，还需要再进一步攻破内部服务认证/鉴权才能进入单一服务。(当然，API网关上面有可能存储了所有的后端服务的认证凭据，这就是一锅端了。)攻击检测设备有更多时间发现攻击者。

2、安全诉求：若因为考虑安全而设置API网关，此时和业务诉求可能有点不同。

基于安全诉求，一般情况下会这么干：统一认证/鉴权：这个统一就不是API网关来做统一了，有一个单独的IAM，它负责所有的认证鉴权，提供基于组织、基于用户、基于资源等等的大一统鉴权方式，API网关只是IAM的使用方，自己通常不做认证/鉴权或为了效率提供IAM认证鉴权的本地实现，本质上它不管。

其他基于威胁的防御手段非常多，不一一描述了。

至于你提到的TLS，如果已经有其他认证了，TLS只是做加密通信：API网关对外：一般情况下API网关对外提供链接肯定会支持TLS，但也分场景支持明文方式，比如：请求数据只需要保证完整性做防篡改，此时做Hmac即可，不需要做TLS。

API网关对内：内部通信做转发时，视组网和业务情况而定是否做TLS，需要综合考虑平衡性能和安全。如果要做，可以考虑：HTTP2.0+TLS1.3，效率有较大提升。对外也可以这么做，但是用户客户端不一定支持这两个协议。

我的意见，综合：一般情况下，由于各种服务和API网关出现的时间点不一定一致，没有网关的时候我服务难道就不认证了吗？而且服务形态不同，认证方式可能也不同，比如：我支持用户名口令，网关支持AK/SK。所以各做各的没问题，存在多套认证是合理的。

API网关自己不适合做统一认证/鉴权，这个事情是IAM做的，要统一是IAM的事。

如果也没有IAM，那么API网关做了这个事也不应该影响后端服务，理论上对后端服务应该是完全透明的。