0

The big picture is:

  • an android application which authenticate user with an external openid provider (such as azure AD)

  • a Java EE server which expose rest endpoints securized with the validation of the jwt token generated by the openid provider and appendend by the android application on each request

What is the best way to encrypt each request?

I saw JWE but it seems that it encrypt only the JWT and it's not clear how to implement JWE with an openid external provider.

Francesco Clementi
  • 101
  • 2

1 Answers1

2

Posting this as an answer as I cannot comment yet:

What is the best way to encrypt each request?

I think forcing your server to run on HTTPS should offer enough encryption, as it obscures most information associated for a REST call such as query or form parameters to a point where an eavesdropper can only make vague assumptions about their respective lengths.

I saw JWE but it seems that it encrypt only the JWT and it's not clear how to implement JWE with an openid external provider

Yes, JWE only obscures the token's contents, which might be desirable depending on whether they hold claims you regard as sensible information such as the user's E-mail address or the issuing organization`s tenant id (none of these are regarded confidential by Azure AD itself). Whether JWE is supported depends on the provider; Azure AD for instance does so. You will have to generate a secret in your app registration to decrypt the tokens on your resource server. But be aware that JWE only is not a sufficient way to encrypt your communication, as an attacker could still just snatch a token off of an unencrypted request and use it maliciously on his behalf.

Beltway
  • 316
  • 1
  • 11
  • Thanks for your comment. For my company https is not enough so I need to find a way to encrypt also the rest content. Do you know how can I accomplish this request? Which is the standard way? Can't find much on internet – Francesco Clementi Sep 27 '21 at 13:13
  • A REST-based web-service is built on top of HTTP. So your "REST contents" (headers, bodies, URL parameters etc.) are encrypted by default. If you want to mitigate additional attack vectors I suggest to rather go for things like strong passwords, 2-factor-authentication and short lived tokens (the latter might not be feasible with external providers). If it is really the encryption of the underlying low-level connection you are concerned about I suggest a look at this question: https://security.stackexchange.com/questions/178315/do-i-need-additional-encryption-on-top-of-https-for-a-rest-api – Beltway Sep 27 '21 at 13:28
  • I understand that HTTPS is enough, but some APIs will contain sensitive content such as keys. Do we really need to implement content encryption on our own without any standard way? – Francesco Clementi Sep 28 '21 at 07:55
  • Does contain mean the API provides keys to or receives them by the client? Again, transfer is encrypted and no eavesdropper could read the key in plain text. Provided these keys are not permanently stored on the client app I fail to see the issue here. – Beltway Sep 28 '21 at 08:11