I'm exploring the use of IdentityServer with an API Gateway.
The API Gateway would do the following:
IdentityServer presents a few challenges with this today.
The API Gateway is just a reverse proxy that doesn't care about scopes (the backend resource validates the scope). With its needs for introspection, the API Gateway needs to be configured as an ApiResource. Because an ApiResource requires at least one scope, this would require the ApiResource of the API Gateway to contain a list of all scopes known to the backend resources. This may not be ideal. I realize it does add some complexity to the ResourceStore implementation, but it would be great to have a "allow any known scope" option that could be placed on an ApiResource.
In a single request, the reference token needs to be resolved by IdentityServer twice. The first time is by the API Gateway. From there, the token could be just forwarded along (poor man's delegation), requiring the backend to also go through introspection. Alternatively, a custom grant could be set up so that the API Gateway could acquire a JWT to pass on to the backend. Either way it means a second round trip. It would be helpful for introspection to optionally return an equivalent JWT that could be forwarded. This could be theoretically achieved today by implementing a custom IIntrospectionResponseGenerator, but I'm not sure if this is the kind of thing you have in mind for #507.
Interesting scenarios. We could possibly implement some things in IdSvr to accommodate you, but I'm wondering if it'd just be easier (and perhaps faster) for you to build your own custom API co-hosted with IdentityServer to do both tasks with one endpoint.
Building that functionality as a custom endpoint within my instance running IdentityServer (leveraging services) probably wouldn't be very hard. The downside is clients would then be unable to leverage existing tooling to handle things like authentication, introspection and caching. I'd probably want to avoid that, especially given the polyglot nature of clients.
The "allow any known scope" concept is really more a matter of simplifying administration of an ApiResource. It could probably be accomplished with a complicated query within a custom ResourceStore implementation without having to touch the application as it is. I'd like to see it as a more first class feature. I can to put together a pull request where I'd add a "AllowAnyKnownScope" property to ApiResource, integrate the property within IntrospectionRequestValidator and IntrospectionResponseGenerator, and add the appropriate tests. If that functionality is something you feel would be appropriate for the application, I'm happy to contribute there.
As for adding a JWT within introspection, I think that extending the introspection endpoint response #507 would help there, and that discussion goes beyond the API Gateway use-case and I'd like to take that part of this discussion over there.
I had a quick look - the endpoint extensibility could probably be cleaner - but wouldn't implementing your own IIntrospectionResponseGenerator totally work for your requirement?
Yes, all of what I discussed above could be achieved with the IdentityServer as is. The exchange for a JWT could be achieved by replacing IIntrospectionResponseGenerator, but that would require this existing logic to be copied into the new class. Allowing any scope would also require an extended version of ApiResource to contain the new property which is also doable.
I more raised the question because what I'm describing feels like a common architectural pattern to me. By that, I mean having an "outer" service (an API gateway, an authorization check, or a microservice whose only job is to call other services and aggregate their results) receive a reference token and wanting to forward a JWT to an "inner" service without the need for additional round trips to the IdP during a single request.
So is this a common use case for others? And if so, is this feature something desirable to be included in IdentityServer itself? I can put together a PR if so.
I already have an issue for that, but it will be a breaking change and thus needs to wait for v2.
That works
@leastprivilege so then is this issue a dup of another one? if so, i guess we can close this.
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Most helpful comment
Yes, all of what I discussed above could be achieved with the IdentityServer as is. The exchange for a JWT could be achieved by replacing
IIntrospectionResponseGenerator, but that would require this existing logic to be copied into the new class. Allowing any scope would also require an extended version ofApiResourceto contain the new property which is also doable.I more raised the question because what I'm describing feels like a common architectural pattern to me. By that, I mean having an "outer" service (an API gateway, an authorization check, or a microservice whose only job is to call other services and aggregate their results) receive a reference token and wanting to forward a JWT to an "inner" service without the need for additional round trips to the IdP during a single request.
So is this a common use case for others? And if so, is this feature something desirable to be included in IdentityServer itself? I can put together a PR if so.