I'm having issues finding the right language to search for answers to my problem so hopefully I can explain it here.

I am trying to create an API that will be accessed by a 3rd party. This 3rd party authenticates their users using some unknown system (they use something like auth0 or Okta). Their web application will be making requests to our API on behalf of the users. We need to validate the these requests are coming from authenticated users from the specific 3rd party, but we don't want to keep track of the 3rd party's users. We need these requests to have tokens containing claims pertaining to the individual user, but it would be up to the 3rd party to handle these claims.

Is what I'm describing here possible? I've been reading up on Federated SSO, but it doesn't quite seem to solve the problem that we're having.

  • I'm not confident enough to write an Answer, but I believe that standard SAML / OIDC / whatever will do this. Your app would be a Relying Party (ie you are relying on the claims that the Identity Provider signed). In this case, the application in the middle is also a Relying Party, and would be relaying those claims to you. Jan 23, 2020 at 22:20

1 Answer 1


Sounds like you are looking for a secure way to authorize requests server-to-server. As the 3rd party handles the authentication, you just need to verify requests are coming from the 3rd party.

How about using JSON Web Tokens (JWT)? They can be encrypted to provide confidentiality but are also digitally signed using a public/private key pair that ensures integrity and authenticity of the data sent between your API and the 3rd party.

  • I agree that the OP is effectively describing server-to-server authentication - great catch! However, JWTs are a poor fit for server-to-server authentication. They are really designed for client communication. There are any number of server-to-server authentication methods. Feb 23, 2020 at 11:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .