简体   繁体   English

API网关+登录微服务+redis

[英]API gateway + Login microservice + redis

I am developing a web application and I am trying to design and implement a microservices architecture.我正在开发一个 web 应用程序,我正在尝试设计和实现微服务架构。 I've been reading a lot about authentication and authorization and I would like to know if with my design I am on the right track.我已经阅读了很多关于身份验证和授权的文章,我想知道我的设计是否走在正确的轨道上。

I have an API gateway that manages all the communication flow between the frontend application and the back end services.我有一个 API 网关,用于管理前端应用程序和后端服务之间的所有通信流。 Behind the gateway I have two microservices called identity provider and frontend microservice respectively.在网关后面,我有两个微服务,分别称为身份提供者和前端微服务。 The identity provider manages things as login, registration and deliver access tokens.身份提供者管理诸如登录、注册和交付访问令牌之类的事情。 The frontend microservice contains an angular app.前端微服务包含一个 angular 应用程序。 So, in a normal flow the user would authenticate with the identity provider that, in turn, open a login session stored in redis and gives the session id back as a cookie.因此,在正常流程中,用户将向身份提供者进行身份验证,身份提供者依次打开存储在 redis 中的登录名 session,并将 session id 作为 cookie 返回。 The identity provider redirects the user to the frontend service that check the login status stored in redis and, only if authenticated, returns the angular app.身份提供者将用户重定向到前端服务,该服务检查存储在 redis 中的登录状态,并且仅在通过身份验证后返回 angular 应用程序。

So, I am not using OAuth because I think I don't really need it at this very moment.所以,我没有使用 OAuth,因为我认为此时此刻我真的不需要它。 Also I am not managing authentication at gateway level.此外,我不在网关级别管理身份验证。 Is it a good approach to have a microservice for the login and redis to store the session, so that all the other microservices can authenticate the user when needed?为登录和 redis 存储 session 的微服务是否是一种好方法,以便所有其他微服务可以在需要时对用户进行身份验证? I see a lot of examples to implement authentication at gateway level, so is it a bad approach to delegate the microservice to authenticate the user?我看到很多在网关级别实现身份验证的示例,那么委托微服务来对用户进行身份验证是不是一种糟糕的方法? In a way that the gateway only works as a router.在某种程度上,网关仅用作路由器。 What do you think about this?你怎么看待这件事?

Storing user session on Redis is not bad practice, however using Redis for authorization/authentication purposes could result in security issues.将用户 session 存储在 Redis 上并不是一个坏习惯,但是使用 Redis 进行授权/认证可能会导致安全问题。 In an ideal microservice architecture, services need to be as stateless as they can.在理想的微服务架构中,服务需要尽可能无状态。 By giving the authorization job to redis you are creating an extra layer that you need to manage on every request.通过将授权作业授予 redis,您将创建一个额外的层,您需要在每个请求上对其进行管理。 What will happen when user info changes?当用户信息发生变化时会发生什么? You will need to update redis too and when it is out of sync with the Authorization server, then problems will start to emerge.您还需要更新 redis,当它与授权服务器不同步时,问题就会开始出现。 It is also not bad practice to use separate Authorization server behind your gateway.在网关后面使用单独的授权服务器也不是坏习惯。

When you are using an API-GATEWAY,you must keep in mind that in Microservice architecture we have to handle cross cutting concerns in Api-Gateway.Means,once you put some functionality like security , logging , user tracking in one place to perform to entire application zone and when you want to change them,you change one place not entire microservices,.,.So,you can use oauth2 with spring cloud gateway or zull as a oauth2 client and use Oauth2 provider.After successful login,gateway performs TokenRelay(removes cookie from request and replace it with jwt token and send it to your microservices).Now you can use Redis as a HttpSession management in your gateway.Also with this approach you can use multiple instance of your services.当你使用 API-GATEWAY 时,你必须记住,在微服务架构中,我们必须处理 Api-Gateway 中的横切关注点。意味着,一旦你将一些功能(如安全性日志记录用户跟踪)放在一个地方来执行整个应用程序区域,当你想改变它们时,你改变一个地方而不是整个微服务,.,.所以,你可以使用 oauth2 和 spring 云网关或 zull 作为 oauth2 客户端并使用 Oauth2 提供者。成功登录后,网关执行 TokenRelay (从请求中删除 cookie 并将其替换为 jwt 令牌并将其发送到您的微服务)。现在您可以将Redis用作网关中的HttpSession管理。此外,通过这种方法,您还可以使用服务的多个实例。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM