Upstream Authentication using Request Signing
Last updated:
Request signing
Request Signing is an access token method that adds another level of security where the client generates a unique signature that identifies the request temporally to ensure that the request is from the requesting user, using a secret key that is never broadcast over the wire.
Tyk can apply either the symmetric Hash-Based Message Authentication Code (HMAC) or asymmetric Rivest-Shamir-Adleman (RSA) algorithms when generating the signature for a request to be sent upstream. For HMAC, Tyk supports different options for the hash length.
The following algorithms are supported:
Hashing algorithm | Tyk identifier used in API definition |
---|---|
HMAC SHA1 | hmac-sha1 |
HMAC SHA256 | hmac-sha256 |
HMAC SHA384 | hmac-sha384 |
HMAC SHA512 | hmac-sha512 |
RSA SHA256 | rsa-sha256 |
This feature is implemented using Draft 10 RFC. The signatures generated according to this standard are temporal - that is, they include a time stamp. If there is no Date
header in the request that is to be proxied to the upstream, Tyk will add one.
Configuring Request Signing in the API definition
Upstream Authentication is configured per-API in the Tyk Vendor Extension by adding the authentication section within the upstream
section.
For Request Signing, you must configure upstream.authentication.upstreamRequestSigning, providing the following settings:
- the
signatureHeader
in which the signature should be sent (typicallyAuthorization
) - the
algorithm
to be used to generate the signature (from the table above) - the
secret
to be used in the encryption operation - optional
headers
that Tyk should include in the string that is encrypted to generate the signature - the
keyId
that the upstream will use to identify Tyk as the client (used for HMAC encryption) - the
certificateId
that the upstream will use to identify Tyk as the client (used for RSA encryption)
The Tyk Classic equivalent is request_signing.
Configuring Request Signing with Tyk Operator
When using Tyk Operator, the certificateId
and secret
are encapsulated in Kubernetes references:
certificateRef
: references a Secret containing the private and secret key.secretRef
: references a Kubernetes Secret that holds the secret used in the encryption operation.
For example:
|
|
In this example, a Tyk OAS API was created using the upstreamRequestSigning
field. It can be broken down as follows:
upstreamRequestSigning
: This defines the settings for Upstream Request Signing. in the example manifest, it configures Upstream Request Signing using thebooking
API.certificateRef
: References a Secret containing the private and secret key for signing client API requests. This should be used ifsecretRef
is not specified.secretRef
: References a Kubernetes Secret that holds the secret key for signing client requests.algorithm
: Specifies the algorithm used for signing.- For
secretRef
, supported algorithms include:hmac-sha1
,hmac-sha256
,hmac-sha384
, andhmac-sha512
. - For
certificateRef
, the required algorithm isrsa-sha256
.
- For
keyId
: A user-defined key assumed to be available on the upstream service. This is used in theSignatureHeader
and should be included when usingcertificateRef
. It is required when using the RSA algorithm.