OpenID重定向与承载 [英] OpenID redirect vs bearer

查看:111
本文介绍了OpenID重定向与承载的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在使用C ++开发微服务(出于低延迟的原因),并且我开始涉足OpenID和Keycloak.用C ++开发意味着我几乎没有对OpenID的库支持,但是(希望)所有低级别的细节都可以正常工作(例如正确的JWT验证).我必须进行所有通信流程并重定向自己.

与背景无关.请记住这一点,因为我需要知道并实现通常会为开发人员隐藏的库的细节.

我的申请中包含三方:

  • Web客户端W
  • 微服务A
  • 微服务B

这三者之间的一般通信:Web客户端W可以是前端UI或仅使用API​​作为服务而没有任何前端的移动设备. W连接到微服务A来操纵和使用微服务A中的数据.微服务A与微服务B交换数据,反之亦然. W不需要了解B.

到目前为止,我想到了以下架构:

  • 从Web客户端到微服务的通信我将使用专用用户和Keycloak中访问类型为"Public"的客户端来允许用户/密码登录
  • 对于微服务A到微服务B的通信,我将使用访问类型承载,因为它们从不发起任何登录

如果您认为这听起来不正确,请告知.但是,我的实际问题是,需要哪种登录流程以及之间可能错过的哪一步:

  1. 可以在微服务A上具有用于登录的终结点吗? https://servicea.local/login 将Web客户端的请求重定向到OpenID/Keycloak.例如. Web客户端将用户名,密码,客户端ID和授予类型发送到OpenID令牌请求端点解决方案

身份验证(委托给Keycloak),然后通过直接联系keycloak来获取令牌,令牌应从UI to A to B传递

以下是密钥斗篷提供的OIDC端点

https://www .keycloak.org/docs/latest/server_admin/index.html#keycloak-server-oidc-uri-endpoints

I'm developing a microservice in C++ (for low latency reasons), and I'm beginning to dive into OpenID and Keycloak. Developing in C++ means I've almost no library support for OpenID, but I've (hopefully) the all the low level details working (like proper JWT verification). I've to do all the communication flows and redirects myself.

So much as a background. Keep that in mind because I need to know and implement details which usually a library will hide for a developer.

There are three parties in my application:

  • A web client W
  • Microserice A
  • Microservice B

General communication between those three: The web client W could be either a frontend UI or a mobile device using just the API as a service without having any sort of frontend. W connects to microservice A to manipulate and consume data from it. Microservice A exchanges data with microservice B and vice versa. W does not need to know about B.

So far I thought of the following architecture:

  • For the Web Client to Microservice A communication I'd use dedicated users and clients with access type "Public" in Keycloak to allow user/pw logins
  • For the Microservice A to Microservice B communication I'd use Access Type Bearer because they never initiate any login

Please advise if you think that does not sound right. My actual question is however what kind of login flow(s) is required and which step there are in between which I may miss:

  1. Is it ok to have an endpoint for the login on microservice A https://servicea.local/login which redirects the requests of the web client to OpenID / Keycloak. E.g. the web client sends username, password, client id and grant typeto the OpenID token request endpoint http://127.0.0.1:8080/auth/realms/somerealm/protocol/openid-connect/token ?

  2. Should the client take the token and add it to all subsequent calls as authorization token?

  3. Should the Microservice implement a callback to retrieve the authorization information?

  4. Should the flow instead be changed for the client to service communication to provide an access code to he service which it exchanges with an access token?

解决方案

Authentication (delegating to Keycloak) and then getting Token should be done by your UI by directly contacting keycloak and that token should be passed on from UI to A to B

Here are the OIDC endpoints that keycloak provides

https://www.keycloak.org/docs/latest/server_admin/index.html#keycloak-server-oidc-uri-endpoints

这篇关于OpenID重定向与承载的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆