Passing user identity to a different REST service

Question

I have two use-cases I am trying to solve.

1. A HTTP Service-A hosted on XYZ domain tries to access HTTP Service-B on ABC domain. Service-B is a stateless HTTP API which does not have user concept. Service-A maintains user information. Task is to securely transmit logged-in user details like their name, email in every API call from Service-A with Service-B over HTTPS. What is the recommended way to do this? Do you think using encrypted JWT token and passing it as bearer token is the only way for this? i.e., Service-A encrypts with public key and Service-B decrypts with private key.

2. User logs into XYZ.com and tries to access a feature which redirects them to feature.XYZ.com (they are on same domain XYZ.com). feature.XYZ.com does not have user concept and it is stateless. Task is to securely transmit logged-in user details like their name, email to feature.XYZ.com over HTTPS. What is the recommended way to do this? Do you think using encrypted JWT token as a cookie is the only way for this? Thinking of asking XYZ.com to maintain the cookie timeout same as session timeout so when the user logs out of XYZ.com manually or due to inactivity, they also can't access feature.XYZ.com anymore.

Please let me know if you need more information. Thanks!

Answer 1

The ID token containing a claim about the current user must by signed, otherwise the receiver of the token cannot validate that it was issued by the sender it claims. This means that the receiver must trust the sender: it must know the sender's public key to verify its tokens.

But this still leaves open the possiblity that the sender makes up the identity of the user. To avoid that, the ID token must be issued (and signed) not by the sender but by an identity provider that is trusted by both sender and receiver not to make up user identities. These ID tokens would be short-lived and issued only while the user is still logged to the sender application.