2 Legged auth

[mkulikk]

Hi,

I'm going to implement two legged authentication into kong-oidc plugin.

The flow should work as follows:

• Users request an access token from AS by using their credentials.
• Users make a call into application behind kong with access token in Authorization header.

Guessing that "require("resty.openidc").introspect(opts)" will do the job.

But besides that we need to put the userinfo into upstream. It can be done by obtaining ID token with user info or just call userinfo endpoint.

It can be done by using "openidc_call_userinfo_endpoint" (private) method in lua-resty-openidc library or create new method that does it inside library. Unfortunatelly there are no public methods in lua-resty-openidc that provides such functionality out of the box, so modifications will be needed in this case (at least make "openidc_call_userinfo_endpoint" public).

Also the "sub" field can be extracted from json provided by introspection method "require("resty.openidc").introspect(opts)" which provides access token fields in json format. Then only sub field will be set as id into ngx.ctx.authenticated_consumer.id. X-Userinfo header will not be provided and getting userinfo will be on target application hands (This solution is better I think).

What do you think ?

[Trojan295]

In a two legged flow there is no user (Resource Owner in OAuth terms) involved. The OAuth client makes calls as itself. I don't think you can use Userinfo endpoint with a two legged flow, as there's no user. The subject field will be empty.

Generally a Relaying Party isn't involved in a two legged flow. Such calls shouldn't go through it. IMO, this plugin should be disabled for Kong APIs, which are used in two-legged flows.

[zandbelt]

There's some OIDC/OAuth terminology used incorrectly here but the first part of use case is already supported. A client operated by a user (Resource Owner) can obtain an access token using the Resource Owner Password Credentials flow at the AS (that's all out of scope of lua-resty-openidc though) and present that access token to lua-resty-openidc that can validate/introspect it.

Pushing the info resolved from the introspection upstream would typically be done in headers. That's also easy to do in Lua. This is all pure OAuth 2.0.

A userinfo endpoint is OIDC specific and this may not be available or known in a pure OAuth 2.0 play where an access token is presented to lua-resty-openidc.

[Trojan295]

@zandbelt What about, when you have a Resource Servers behind Kong? I would like to protect the resources there with UMA/role based authorization, which is handled by the AS. Is a Relying Party in this case redundant, cause the Resource Server has already an authorization mechanism enabled?

[zandbelt]

I believe so. lua-resty-openidc doesn't support UMA. It can function as an OAuth 2.0 Resource Server on its own so components running behind Kong can offload that function (comparable to SSL termination). But if you have APIs sitting behind Kong that are OAuth 2.0 Resource Servers on their own that can validate access tokens, lua-resty-openidc doesn't add much. Relying Party is an OpenID Connect term which, I think, is not in play here.

[Trojan295]

I'm thinking about this open MR here #12. I have a feeling, that it's adding some functionality, which shouldn't be covered by a Relying Party. This MR adds an option to make calls, which already have a token (so there is already an client, who makes requests). This could be used, if there is an UMA Resource Server behind Kong and you want make requests with an RPT. But.. wouldn't it be easier to simply disable the plugin for such API routes and keep only the reverse proxy functionality of Kong? If there's an UMA protected client behind Kong, it will protect itself without any need for a RP on Kong.

[mkulikk]

UMA is not the scope of this plugin. This plugin enables already authenticated users to access APIs behind kong

[phirvone]

FIxed in version 1.0.3.