Hi Sujith
No - there is no way to encrypt with a private key and decrypt with a public key. It is not possible with that callout, nor with any other RSA-based crypto. That's not how RSA works.
Let's get some foundations in place. There are two options for crypto: signing, and encryption. It's a little nuanced because you can perform signing or encryption with either symmetric keys (aka secret keys, shared keys) or asymmetric keys (public+private keys). For the rest of this answer, let's just focus on the asymmetric key case - that is the case where you have an RSA key pair. There are other types of asymmetric keys, too, but that's not particularly important at this level.
Signing is performed using a private key. The signed document can then be shared, along with a reference to a public key. If your signing "format" is JWT, then the public key reference is usually a JWKS endpoint. If you trust the validity of the JWKS endpoint, for example if it is anchored at http://www.the-signing-party.com/.well-known/jwks , then you know that "the-signing-party" has published the public keys that are available on that JWKS. So you retrieve a public key via an ID lookup, and verify the signed document using that public key. If the signature validates, then you can be assured that the signing party really did sign the document, with a private key that the signing party possesses, and which corresponds to the public key you used.
Encryption is different. With Encryption, the encrypter uses a PUBLIC key. The encrypter won't "own" or "possess" the private key. The idea is, I'm going to send a message to Bob, and I want only Bob to be able to read it, so I will encrypt the message with Bob's public key. Then I can transmit the message to Bob, and be assured that only Bob has the private key, which Bob can use to decrypt the message and expose its details.
This is how signing and encryption works. The use of the public key for encryption is not a "design choice" I made in the implementation of the Java callout you cited. It's just how RSA crypto (or more generally asymmetric key crypto) works.
If not, is there any implementation/solution i can utilize using apigee(on premise)?
Some people use a hybrid approach, in which they use BOTH encryption and signing. Often, this is done by signing a JWT (using a private key) , and then embedding that into an encrypted blob, like an encrypted JWT or a JWE. This is common enough that it is explicitly described in the JWT specification, RFC 7519, in section 11.2 .
While syntactically the signing and encryption operations for Nested JWTs may be applied in any order, if both signing and encryption are necessary, normally producers should sign the message and then encrypt the result (thus encrypting the signature). This prevents attacks in which the signature is stripped, leaving just an encrypted message, as well as providing privacy for the signer. Furthermore, signatures over encrypted text are not considered valid in many jurisdictions.
If you want to do that in Apigee, you would use the builtin policy to generate a signed JWT, and then you se the callout you referenced to construct a JWE with the signed JWT as the payload. But, you need to be thoughtful about the keys here. Sign with the private key that belongs to Apigee, then encrypt with a PUBLIC key, for which the intended receiver possesses the matching private key. (ie, the public key of the Bob character in the example I gave above). The receiver would then:
- use its own private key to decrypt the JWE
- lookup the public key of the signer to verify the signature on the "revealed" signed JWT, that has been decrypted.
LinkedIn
Twitter
