Client to Client (not resource) token validation

[engenb]

Hello,

Not really a problem here, just checking on preferred approach/best practices.

My scenario: A suite of microservice apis that perform various duties (store data, send email, etc) which are secured with oauth/oidc via identityserver4.

Client apps sit on top of these apis and authenticate users through identityserver, and pass the resulting access token along when interfacing with the microservice apis mentioned above.

If a client appA needs to call an api on client appB, we cannot use the introspection endpoint to validate the access token because client appB is a client, NOT a resource, and thus doesn't have a resource scope to authenticate with the introspection endpoint.

Instead, our approach is to use the access token to hit the userinfo endpoint. if we get claims back we're all good, if not, 401.

Is this the expected approach or are we headed down the wrong path?

Thanks much!

[leastprivilege]

Instead, our approach is to use the access token to hit the userinfo endpoint. if we get claims back we're all good, if not, 401.

The userinfo endpoint is def not suitable for token validation.

You basically lost me at this sentence:

If a client appA needs to call an api on client appB

There are clients and there are APIs - they are distinct entities, so the above sentence does not make sense to me. Can you elaborate? Also - why introspection?

[engenb]

sure, I'll do my best to clarify.

my company has built a collection of microservice web apis as a BaaS platform - what this currently means to us is these services have no business logic. examples would be a service that sends sms messages or a service to facilitate realtime message delivery. these service apis are all secured with an implementation of IdSrv, which is also a service in that BaaS platform - I'll refer to this as "Platform". each service in the Platform has a respective resource scope and secret in IdSrv. these services perform token validation with the IdentityServer4.AccessTokenValidation package by supplying ApiName/Secret.

it may be important to note that we're doing reference tokens, not JWTs.

my company is also building a suite of collaboration products on top of the Platform - I'll refer to these as "Product"s. When users access Products, they are redirected to IdSrv to get authenticated. native apps are using hybridPKCE and our web apps are currently using hybrid with cookies, but we're transitioning that over to implicit as these are SPAs and cookies are no bueno for SPAs. each Product is a different client in Idsrv. This is all working great.

as these Products are expected to facilitate collaboration, they need some shared services to contain shared business logic across the Products. a user workflow service could be an example of one of these shared Product services - we'll call this "Workflow". Workflow contains a lot of business logic shared throughout our Products, so it will not be a part of the Platform and thus is not expected to have a resource scope in IdSrv. it is just another client in Idsrv. to my knowledge, this means Workflow cannot validate tokens with the token introspection endpoint (via IdentityServer4.AccessTokenValidation). it makes sense that a token granted for a Product client in IdSrv would never be valid for any other client such as Workflow in this case.

If a Product sends a request to Workflow, Workflow can't validate the Product token because they are different IdSrv clients. this is where we initially thought we could use the userinfo endpoint.

if userinfo endpoint is not an appropriate way to verify reference tokens, our current options we're thinking through:

1. switch to JWTs and let APIs validate tokens locally
2. Product suite needs its own IdSrv which delegate to Platform IdSrv as external auth provider

thanks for your advice on this - we really appreciate it!

[TomCJones]

The concept you are describing requires some central "anchor point" to assure trust among the providers. Enabling these "clients" as openid constructs requires that each of them get user consent to share information. Since you are AFAICT inside an enterprise that coerces employees and contractors to sign away their rights, the IdP could infer consent, but now you're outside the scope of OpenID.

The idea that could help is that of a "trust framework". I have written this about trust frameworks, but it is not yet at the point of being a finished spec, just a set of requirements. https://wiki.idesg.org/wiki/index.php?title=Trust_Framework_Membership_Validation

[TomCJones]

I guess I never will understand why people try to use an OpenID inside a closed system.

[zeitlerc]

I'm a coworker of @engenb . We built a Platform which provides an IdSrv and other services. We are building SPA applications on the Platform, but trying to treat the Platform as external and generic so we can create unrelated applications that use the same Platform. The SPA applications want to use Implicit Flow with the Platform's IdSrv. Each SPA has it's own Client, so a client ID and secret. The SPA is not a resource so it does not have it's own scope or scope secret, and therefore cannot use the introspection endpoint. Right now, the SPA application uses cookie authentication for the browser and does not have the ability to verify the reference token. However, we still need the reference token to use Platform services like sending email, which uses the subject claim to identify the user. We're trying to avoid managing multiple instances of IdSrv by only using the Platform IdSrv for every SPA application. We also want to add some micro-services that sit between the SPA and the Platform, which would additionally need to verify the reference token. Our first shot is using the User Info endpoint to verify that the reference token is active and cross-check some claims. It sounds like that is not the way to go. Is there another feasible solution? Our next path might be adding the SPAs as resources in the Platform IdSrv.

[leastprivilege]

I really think you need a bit of consulting to get your base architecture right. The issue tracker is not the right place for that.

https://identityserver4.readthedocs.io/en/release/intro/support.html

Each SPA has it's own Client, so a client ID and secret.

SPAs use implicit flow - this implies no client secret

Right now, the SPA application uses cookie authentication

that's the next problem

we still need the reference token

why reference tokens?

Our first shot is using the User Info endpoint to verify that the reference token

that's wrong

Our next path might be adding the SPAs

that also doesn't make sense to me.

[lock[bot]]

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.