3

I have a resource that generates a tokens for users. I want to add possibility choose token generation algorithm.

I can't change request structure but can add some HTTP header with the algorithm name. My question is what header to choose? Would Accept be acceptable?

I currently use a Accept-Token-Algorithm header to send values like RS256 and HS256.

cassiomolin
  • 124,154
  • 35
  • 280
  • 359
gabba
  • 2,815
  • 2
  • 27
  • 48

2 Answers2

5

My question is what header to choose? Would Accept be acceptable?

There's no standard header for that purpose.

If both client and server agree with Accept-Token-Algorithm, that seems to be a reasonable choice. More descriptive (and verbose) alternatives would be Accept-Token-Signature-Algorithm (assuming the JWT is actually a JWS) and Accept-Token-Encryption-Algorithm (for JWE).

Keep in mind that your API is as good as the documentation you provide for it and custom headers are not obvious to API consumers. So ensure that you document it properly.

You also should consider falling back to a default algorithm if the desired header is not present in the request and ensure that you validate the values you receive. Refer to the RFC 7518 for a list of valid algorithm for each purpose:

Have a look at this page for details on how to choose algorithms for JWT.

Community
  • 1
  • 1
cassiomolin
  • 124,154
  • 35
  • 280
  • 359
1

If you need to add a custom header to your request see Custom HTTP headers : naming conventions

That being said, I don't see any reason for the client to choose the signature algorithm. The signature choice should be decided by the service issuing it and should depend on security tradeoffs acceptables for this service.

APIs accepting this token should be able to verify the signature of this token. So it is APIs consuming this token that should be able to accept the same encryption algorithm and should have access to corresponding public keys (or shared secret) that was used when issuing the token.

If the contents of the token (payload) are useful for intermediary parties, it can be decoded (base64) withouth any knowledge of the encryption algorithm used to sign the key.

If the token is issued for a third party service (such as in oauth2 protocol), the token should be opaque for this kind of actors.

dral
  • 176
  • 3
  • thanks for attention and effort, the reason to choose algorithm by client is because we can't store private key on some services and need to switch to asymmetric signing algorithm. The both token types will valid, and can be validated without additional requests. – gabba Oct 22 '18 at 07:31