微服务 api授权是什么？
api授权是什么？
最近，我在考虑微服务网关的身份验证和授权，以保护API。我的理解是，当客户端访问API时，它将由网关进行身份验证。如果身份验证通过，将调用API。否则，将返回403，用户将输入密码和帐户进行身份验证。但我不明白的是，如果这个网站，比如淘宝网，不用登录就可以访问，那么这个API就不用认证客户端就可以调用了，这和上面对认证和授权的理解是不同的，或者其他API接口的授权和认证意味着别的什么。
企业级微服务架构下API保护和控制层如何做？
在spring云方面，要实现API的认证和保护，需要与JWT技术（无状态）合作。一般有两种方法：
方法一：
直接在网关中设置各种过滤器，配置一定的路由拦截规则，将部分用户认证码编码到网关中，实现网关端的初步认证和认证。这意味着超过90%的系统认证是在网关上进行的。所有客户端都请求网关的地址，而不是微服务的实际地址。当请求通过nginx到达springcloud网关时，网关取出请求的前缀，然后根据代码中配置的pre、post、error等过滤器选择相应的过滤器。网关根据请求中携带的JWT信息，解析后取出凭证信息，如果用户中心返回正确结果，则执行用户定义的登录认证逻辑（一般网关服务调用用户中心服务进行检查），网关服务接收响应结果，向筛选器返回NULL，并请求继续向其他微服务发送。执行相应的业务逻辑后，相应的业务服务将结果返回给网关，网关通过nginx将结果返回给客户端。
方法二：原理同上，区别在于一个新的微服务叫做用户授权认证中心。当请求到来时，网关只做最基本的请求验证，如JWT格式是否合法，JWT是否过期，不再对用户进行认证操作，即不在网关中查询用户，而是调用用户授权认证中心，通过必要的参数到中心对应的HTTP方法中，请求后得到结果并返回给网关，然后网关给出客户端特定的信息，如果认证失败，将返回给客户端。如果身份验证成功，它将在网关筛选器中释放。这意味着网关的工作要少得多，90%以上的认证操作都在授权认证中心进行。
这两种方法都可以使用，但建议使用第二种方法，这更符合微服务的理念。第一种适用于项目的初始阶段。当规模不大时，可以暂时使用。当流量出现时，网关将无法承受，因此从长远来看，需要开通新的微服务来分流流量。
版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。
