3

Premise:
- Two services A and B
- Resource X has owner U, and is managed by service B

Now, I need to handle these auth scenarios:
1- End-user needs to directly use service B's API to access X
2- Service A needs access to X, because end-user made a call to A (i.e. delegation)
3- As part of a async comms (e.g. a job or an event), service A needs access to X. (no end-user involved)

I've been researching a lot (a month now), but still feel confused. For example, I've looked at oauth/jwt integration with Kong, but it wasn't clear how #3 above would fit. Istio seems ideal since it can assign identities to services.

If I go with Istio:
- what part of auth will the application (both A and B) be responsible for?
- what will the final (HTTP) request that makes it to the application roughly look like?

3 Answers 3

2

The options you looked at use JWT tokens for the authorization (most of the time at least). The token has all the identity and role information necessary for any one service to make decisions with. It is passed as a bearer token in the Authorization header. The token itself is signed so end users can't hack it to get more privileges, and it has a timeout so you can regularly expire them.

That means, if a web service needs to delegate identity to another service, it merely needs to embed the token in the request it makes. It also means that it is a form of authentication that would survive API proxy delegation.

In the last case, you can use a k8s Secret to supply an authentication token and have the job negotiate a session token to perform its duties. Hopefully you are positively identifying and verifying the identity of all code that is accessing your system. In systems I manage, the asynchronous jobs have to negotiate their JWT token just like any other client:

  • Exchange the system identification token so I can validate that callers are allowed to interact with my services--and that I can positively identify them in my audit logs
  • Use the session token when making calls to the microservices
  • Pass the session token as a value in my messages so that I can be sure the messages are also from an authorized source
1
  • appreciate your help! Can elaborate a bit on the last point? Who's going to issue the auth token? and negotiate with whom? the job is not a single app, it might be a producer that fires events that other services need to respond to and many service-to-service communications will take place
    – sam46
    Jan 27, 2020 at 14:14
2

I am not sure my approach is extremely safe but I am using an authentication server meaning all requests bear a JWT(Authorization header as stated). Each service that receives a requests asks the Authentication server(http call) if the token is OK and if yes it then responds to the request.

Services can generate their own tokens, but make sure you expire them cause if you don't you risk they are compromised forever, given they become compromised.

How events are now authorized. I suppose it depends on the tool you are using. F.e. https://developer.ibm.com/technologies/messaging/tutorials/kafka-authn-authz/ .

In any case, if you just have your services behind a firewall you might want to consider not using authentication for service to service communication. So, basically you can solve this problem on the deployment domain ;) .

0

Oauth with JWT works for clients auth. But internally, what I needed was a way to give each service an identity.
SPIFFE exists for this purpose, and is implemented by service meshes (e.g. istio on Kubernetes with mTLS)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.