Do we need to authenticate for Internal Microservice?

Question

I have a spa app and three APIs (A, B, C)

A, B are public microservices and C is internal microservice.

Which way is best for that?

1. First way

SpaClient 
Scope = A, B, C

Spa App gets a token of SpaClient from Identity Provider.

Call A api, B api from Spa App using token, and A api calls C api using same token.

2. Second way

SpaClient 
Scope = A, B

CClient
Scope = C

Spa App gets a token of SpaClient from Identity Provider.

Call A api, B api, and A api calls additional to Identity Provider to fetch a token of CClient and call C Api using token of CClient.

This case, Identity Provider needs to generate new token on every request in order to call C Api from A Api.

3. Third way

SpaClient 
Scope = A, B

Spa App gets a token of SpaClient from Identity Provider.

Call A api, B api from Spa App using token, and A api calls C api without token (no authentication in C Api).

Do we need to authenticate for Internal Microservice ?

Answer 1

C Api is a resource which needs to be protected. You can do this on a global level, which may all be fine. But what I think can be a problem is how to access the resource in the flow?

If the resource has user depended information then how are you going to pass this information? A Api can send any sub, claiming it is on behalf of this user. There is no way C Api can tell. And how do you prevent B Api from accessing the resource?

For maintainability and security reasons I would implement the same security on all api's. And in this case the problem can be solved by using delegation.

That way no other resources or clients can access C Api. The resource knows which client made the call and knows for sure it is on behalf of the user they say, as this is part of the access token and can be verified (introspection) by IdentityServer.