I have the following problem:

  • There are 3 parties A, B and X.
  • X is holding 2 entities on behalf of A and B.
  • A communicates with X to operate it's own entity. B also communicates with X to operate it's own entity.
  • Permissions could be revoked at any time for A and B to access their entities.
  • Permission revocation is done by Y.

I want to do all this in a secure way.

First, I will try to boil it down to some requirements. Does this look correct?

  1. I need a secure channel between A <-> X and B <-> X so that no MITM can happen
  2. X needs to be able to authenticate who the caller is. Is it A or B who is trying to access the entity.
  3. X needs to be able to authorize the operation on the entity. That is, is the operation still permitted or revoked?

My proposal:

  1. A (likewise B) contacts Y with it's ID and the permissions it is requesting ( -- OAuth style or something else ... not sure how this works)
  2. Y approves (or rejects) the permission. If approved, it returns back a token ( -- this token is encrypted and can only be decrypted by X. It is signed by Y and X can verify that Y has signed this token. The token contains a unique id as well a a note saying "I verify that the token holder is actually A")
  3. A establishes a TLS channel with X.
  4. A provides the token to X.
  5. X verifies the signature of the token. If successful, A is permitted to perform the operation on it's corresponding entity.


  1. Does this look correct? Any flaws?
  2. What will I do if I cannot use a CA to establish a TLS channel?
  • I wonder why you can't have a CA in this design given that you do rely on a third party for authorization. Of course the access token falls in a different layer but the concept of relying on a trusted third party is already being used
    – Limit
    Commented May 28, 2020 at 1:28

2 Answers 2


You need to ensure the following items for the approach to work:

  • There needs to be a way to ensure that the tokens can't be replayed even if by just A.
  • There needs to be a way for Y to invalidate the tokens. Otherwise A's token will provide them with access even after Y has revoked it.

Also, Is it necessary for the tokens to be only decrypted by X? What if the tokens are just signed by Y and X can read them. This will make the design easier while ensuring that nobody other than Y generates the token.

  • So, for signing how do I distribute the keys? If Y has to sign and X has to read it, then it means Y needs to have the public key corresponding to the private key X has ... How do I do that? I suppose these are general security patterns. Are there standard best practices to solve these sub-problems?
    – user855
    Commented May 28, 2020 at 3:48
  • Similarly is there some standard mechanism to generate Tokens? I don't want to re-invent the wheel here.
    – user855
    Commented May 28, 2020 at 3:50
  • When you sign your tokens, you sign them using your private keys and others use your public key to decrypt it. So Y just needs its private keys and X needs the public keys. As for how to share the keys, it depends a lot on the technology that you use to implement this system
    – Limit
    Commented May 28, 2020 at 4:04
  • @user855 as for the tokens, JWT (jwt.io/introduction) is a token format that people often use. But just to be clear, these recommendations can go out of date so are off topic in the forum
    – Limit
    Commented May 28, 2020 at 4:05
  • What are the examples of technology to share Y’s public key with X? This is called Public Key Infrastructure right? Are there some good open source tools to do that? Do I need a CA to do this?
    – user855
    Commented May 28, 2020 at 14:14

It seems to me that TLS with client side certificates for A and B would get you 90% of the features you need. Having a CA would be fairly critical in my view. It will require some sort of provisioning but would enable you to take advantage of an established strong encryption and mutual authentication system, which is exactly what you need.

Also having X communicate with Y instead of A and B (if this works for you) would help you further simplify the implementation and reduce attack surface.

  • Which 90% will I get with CA?
    – user855
    Commented May 28, 2020 at 14:40
  • Sorry I am not sure what you mean? My point with the 90% meant that most of what you need is provided by TLS, for which a CA is a critical component. Having a CA (even if self signed at the top level) would ensure that you can use the PKI you've established to verify server and client side certificates (for mutual authentication). With TLS in place (which will require provisioning of the clients) you can guarantee a secure channel between A-X, A-Y, B-X, B-Y and X-Y, (as I mentioned it would make sense to consider hiding Y behind X, although I don't know if that works for you).
    – Pedro
    Commented May 28, 2020 at 14:45
  • Ok. So it solves the secure channel problem. It does not solve the authorization problem and doesn’t avoid need for tokens etc. correct?
    – user855
    Commented May 28, 2020 at 14:51
  • Depending on how you implement the system, you could rely on the client side certificates to control access although normally revoking a certificate is not something you can undo. If you need to control access separately to your PKI, you can use your server Y as you suggested either directly consulted by the clients (which would rely in a process whereby X validates this information) or consulted by X on the background. So yeah, the way I see it, TLS will significantly help you control access and ensure channels are secure.
    – Pedro
    Commented May 28, 2020 at 15:15
  • If you need higher level access controls, you need to implement them. Especially if you can contact Y from X directly (which you haven't commented), I don't see the need to use tokens or nonces anywhere.
    – Pedro
    Commented May 28, 2020 at 15:17

You must log in to answer this question.

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