OpenID Connect - 使用JWT的Javascript应用程序的隐式流程,以使用REST API进行身份验证

Jam*_*mes 4 security openid-connect

我正在开发一个Javascript app + REST API.

我希望用户通过OpenID Connect Provider对应用程序(和底层REST API)进行身份验证,以实现SSO目的.

使用Implicit流程我可以获得一个ID令牌(JWT)来识别我的javascript应用程序的用户.我希望我可以在Authorize标头中发送此JWT,以请求我的REST API对用户进行身份验证.但是,这种方法的问题是JWT的'aud'字段不适用于REST API服务器,它适用于javascript应用程序.

这是否意味着隐式流不适合我的用例,或者我错过了什么?

Ale*_*ite 8

Implicit Flow专为不受信任的客户端(例如JavaScript)设计,以获取身份以及(可选)访问令牌.

使用OpenID Connect,您的身份验证请求必须在response_type参数中包含id_token,但它也可以在参数中包含令牌.请参阅规范中的3.2.2.1(http://openid.net/specs/openid-connect-core-1_0.html#ImplicitAuthRequest)

例如

GET /authorize?
response_type=id_token%20token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&scope=openid%20profile
&state=af0ifjsldkj
&nonce=n-0S6_WzA2Mj HTTP/1.1
Host: server.example.com
Run Code Online (Sandbox Code Playgroud)

id_token意味着您将获得您提到的ID令牌.令牌意味着它还将返回一个访问令牌,这是您用于访问REST API的权限.

  • 这花了我一段时间,但我想我现在已经弄明白了!令人困惑的是,我实际上试图实现两件事(有点超出我原来问题的范围).1.身份联合 - 我的Javascript API/REST API只是需要与中央身份提供商合作的更广泛系统的一个组成部分.2.委托访问 - 其他方需要能够代表用户访问REST API. (2认同)
  • 所以我的选择是A)拥有一个授权服务器,它既可以充当身份提供者,又可以发出可以与我的REST API一起使用的访问令牌(要求REST API能够通过某种方式验证所述令牌,这超出了OAuth2规范)或者B)让我的REST API充当授权和资源服务器以及它自己的令牌,恰好使用外部OIDC身份提供程序来验证用户.(原谅我的漫无边际 - 这是我经过数周调查后最终得出的大脑转储,希望对其他人有帮助) (2认同)