{"id":80772,"date":"2026-07-23T14:35:21","date_gmt":"2026-07-23T09:05:21","guid":{"rendered":"https:\/\/www.tothenew.com\/blog\/?p=80772"},"modified":"2026-07-30T15:57:26","modified_gmt":"2026-07-30T10:27:26","slug":"signing-api-requests-with-hmac-in-react-native","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/signing-api-requests-with-hmac-in-react-native\/","title":{"rendered":"Signing API Requests with HMAC in React Native"},"content":{"rendered":"

Introduction<\/h2>\n

HMAC request signing proves two things to your backend: the caller knows a shared secret, and the request was not altered after it was signed. It is not encryption \u2014 the body stays readable \u2014 but it is a strong, lightweight integrity and authenticity check for mobile APIs.<\/p>\n

\n

What is HMAC?
\nHMAC (Hash-based Message Authentication Code) mixes a hash function (usually SHA-256) with a secret key.<\/h2>\n

You pass in:<\/p>\n

    \n
  1. A message string<\/li>\n
  2. A secret both client and server share<\/li>\n<\/ol>\n

    You get back a fixed-length signature (typically hex).<\/p>\n\n\n\n\n\n\n
    \n

    \u00a0 \u00a0 Property<\/strong><\/span><\/h4>\n<\/td>\n

    		\n

    \u00a0 \u00a0 Meaning<\/span><\/strong><\/h4>\n<\/td>\n<\/tr>\n

    \u00a0 \u00a0 Integrity<\/span><\/td>\n\u00a0 \u00a0 Change one character of the message \u2192 signature changes<\/span><\/td>\n<\/tr>\n
    \u00a0 \u00a0 Authenticity<\/span><\/td>\n\u00a0 \u00a0 Only holders of the secret can produce a valid signature<\/span><\/td>\n<\/tr>\n
    \u00a0 \u00a0 Not encryption<\/span><\/td>\n\u00a0 \u00a0 Payload remains readable; HMAC proves who signed it<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    API flow:<\/p>\n

    Client \u2192 build canonical string \u2192 HMAC-SHA256 \u2192 send signature header<\/strong><\/span>
    \nServer \u2192 rebuild same canonical string \u2192 HMAC-SHA256 \u2192 compare (constant-time)<\/span><\/strong><\/p>\n

    Same canonical string + same secret = match. Anything else fails.<\/p><\/blockquote>\n

    \n

    Generate a strong secret<\/h2>\n

    openssl rand -hex 32<\/strong><\/span><\/p><\/blockquote>\n

    That yields 32 random bytes as 64 hex characters \u2014 a 256-bit key that fits HMAC-SHA256 well.<\/p>\n

    Why bother?<\/p>\n\n\n\n\n\n\n
    \n

    \u00a0 \u00a0 Weak choice<\/strong><\/span><\/h4>\n<\/td>\n

    		\n

    \u00a0 \u00a0 Problem<\/span><\/h4>\n<\/td>\n<\/tr>\n

    \u00a0 \u00a0 “mySecret123” \/ app-name keys<\/span><\/td>\n\u00a0 \u00a0 Easy to guess or brute-force<\/span><\/td>\n<\/tr>\n
    \u00a0 \u00a0 Short \/ human-picked secrets<\/span><\/td>\n\u00a0 \u00a0 Low entropy<\/span><\/td>\n<\/tr>\n
    \u00a0 \u00a0 Secrets in git or logs<\/span><\/td>\n\u00a0 \u00a0 Instant leak<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    Use a CSPRNG (openssl rand), store the value in a secrets manager, and never commit or log it.<\/p>\n

    \n

    The canonical string<\/p>\n

    HMAC does not understand HTTP. You pick the fields that matter, join them in a fixed order, then sign that string.<\/p>\n

    METHOD<\/strong><\/span>
    \nPATH<\/strong><\/span>
    \nTIMESTAMP<\/strong><\/span>
    \nCLIENT_PLATFORM<\/strong><\/span>
    \nSECRET_ID<\/strong><\/span>
    \nSIGNED_HEADERS<\/strong><\/span>
    \nBODY_HASH<\/strong><\/span><\/p>\n

    Example:<\/p>\n

    POST<\/span><\/strong>
    \n\/api\/v1\/orders<\/span><\/strong>
    \n1710000000000<\/span><\/strong>
    \nios<\/span><\/strong>
    \nmobile-app-v1<\/span><\/strong>
    \naccept:application\/json;x-api-version:1<\/span><\/strong>
    \na3f2c9… \u2190 sha256 hex of the body<\/span><\/strong><\/p>\n

    More fields \u2192 stronger binding. Each line ties the signature to another part of the request:<\/p>\n\n\n\n\n\n\n\n\n\n
    \n

    \u00a0 \u00a0 Field<\/span><\/strong><\/h4>\n<\/td>\n

    		\n

    \u00a0 \u00a0 Guards against<\/span><\/strong><\/h4>\n<\/td>\n<\/tr>\n

    \u00a0 \u00a0 Method + path<\/td>\n\u00a0 \u00a0 Replaying a body on a different endpoint<\/td>\n<\/tr>\n
    \u00a0 \u00a0 Timestamp<\/td>\n\u00a0 \u00a0 Stale \/ replayed requests<\/td>\n<\/tr>\n
    \u00a0 \u00a0 Client platform<\/td>\n\u00a0 \u00a0 Cross-client misuse of the same secret<\/td>\n<\/tr>\n
    \u00a0 \u00a0 Secret id<\/td>\n\u00a0 \u00a0 Ambiguity during key rotation<\/td>\n<\/tr>\n
    \u00a0 \u00a0 Signed headers<\/td>\n\u00a0 \u00a0 Spoofing headers you care about<\/td>\n<\/tr>\n
    \u00a0 \u00a0 Body hash (bodyHex)<\/td>\n\u00a0 \u00a0 Tampering with the payload<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    Signing only method + path is weak. Bind method, path, time, identity, headers, and body hash \u2014 and keep that list identical on client and server.<\/p>\n

    \n

    Reference implementation<\/h2>\n

    Uses [react-native-quick-crypto](https:\/\/github.com\/margelo\/react-native-quick-crypto). Names are illustrative \u2014 align them with your backend contract.<\/p>\n

    import Crypto from “react-native-quick-crypto”;<\/span><\/strong>
    \nimport { resolvePath, sortBodyKeys } from “.\/signingHelpers”;<\/span><\/strong><\/p>\n

    \/** HMAC-SHA256 \u2192 hex digest *\/<\/span><\/strong>
    \nexport const createHmacDigest = (message, sharedSecret) => {<\/span><\/strong>
    \nif (!sharedSecret) {<\/span><\/strong>
    \nthrow new Error(“Shared signing secret is required”);<\/span><\/strong>
    \n}<\/span><\/strong>
    \nconst hmac = Crypto.createHmac(“sha256”, sharedSecret);<\/span><\/strong>
    \nhmac.update(message);<\/span><\/strong>
    \nreturn hmac.digest(“hex”);<\/span><\/strong>
    \n};<\/span><\/strong><\/p>\n

    const sha256Hex = (data) =><\/span><\/strong>
    \nCrypto.createHash(“sha256”).update(data).digest(“hex”);<\/span><\/strong><\/p>\n

    \/** Build canonical string and sign it *\/<\/span><\/strong>
    \nexport const buildRequestSignature = ({<\/span><\/strong>
    \nmethod,<\/span><\/strong>
    \nurl,<\/span><\/strong>
    \nissuedAt,<\/span><\/strong>
    \nbody,<\/span><\/strong>
    \nsharedSecret,<\/span><\/strong>
    \nsecretId,<\/span><\/strong>
    \nsignedHeaderBlock,<\/span><\/strong>
    \nclientRuntime, \/\/ e.g. “ios” | “android” | “web”<\/span><\/strong>
    \n}) => {<\/span><\/strong>
    \nlet bodyStr = “”;<\/span><\/strong>
    \nif (body != null) {<\/span><\/strong>
    \nbodyStr = typeof body === “string” ? body : JSON.stringify(body);<\/span><\/strong>
    \n}<\/span><\/strong>
    \nconst bodyHex = sha256Hex(bodyStr);<\/span><\/strong>
    \nconst path = resolvePath(url);<\/span><\/strong><\/p>\n

    \/\/ Order must match the backend exactly.<\/span><\/strong>
    \n\/\/ More lines = signature covers more of the request.<\/span><\/strong>
    \nconst canonical = [<\/span><\/strong>
    \nmethod.toUpperCase(),<\/span><\/strong>
    \npath,<\/span><\/strong>
    \nissuedAt,<\/span><\/strong>
    \nclientRuntime,<\/span><\/strong>
    \nsecretId,<\/span><\/strong>
    \nsignedHeaderBlock,<\/span><\/strong>
    \nbodyHex,<\/span><\/strong>
    \n].join(“\\n”);<\/span><\/strong><\/p>\n

    return createHmacDigest(canonical, sharedSecret);<\/span><\/strong>
    \n};<\/span><\/strong><\/p>\n

    \/** Attach time + signature headers to an outgoing request *\/<\/span><\/strong>
    \nexport const signOutgoingRequest = (request, sharedSecret) => {<\/span><\/strong>
    \nif (!sharedSecret) {<\/span><\/strong>
    \nreturn request;<\/span><\/strong>
    \n}<\/span><\/strong><\/p>\n

    try {<\/span><\/strong>
    \nconst issuedAt = String(Date.now());<\/span><\/strong><\/p>\n

    \/\/ Sort body keys so client\/server stringify & hash the same JSON.<\/span><\/strong>
    \nconst sortedBody = sortBodyKeys(request.data);<\/span><\/strong><\/p>\n

    if (sortedBody != null && typeof sortedBody === “object”) {<\/span><\/strong>
    \nrequest.data = sortedBody;<\/span><\/strong>
    \n}<\/span><\/strong><\/p>\n

    const signature = buildRequestSignature({<\/span><\/strong>
    \nmethod: request?.method,<\/span><\/strong>
    \nurl: request.url,<\/span><\/strong>
    \nissuedAt,<\/span><\/strong>
    \nbody: sortedBody,<\/span><\/strong>
    \nsharedSecret,<\/span><\/strong>
    \nsecretId: “mobile-app-v1”,<\/span><\/strong>
    \nsignedHeaderBlock: “accept:application\/json;x-api-version:1”,<\/span><\/strong>
    \nclientRuntime: “ios”, \/\/ or detect at runtime<\/span><\/strong>
    \n});<\/span><\/strong><\/p>\n

    request.headers[“x-request-time”] = issuedAt;<\/span><\/strong>
    \nrequest.headers[“x-request-signature”] = signature;<\/span><\/strong>
    \n} catch (error) {<\/span><\/strong>
    \nconsole.error(“[signing] Failed to sign request:”, error);<\/span><\/strong>
    \n}<\/span><\/strong><\/p>\n

    return request;<\/span><\/strong>
    \n};<\/span><\/strong><\/p>\n\n\n\n\n\n\n
    \n

    \u00a0 \u00a0 Field<\/span><\/strong><\/h4>\n<\/td>\n

    		\n

    \u00a0 \u00a0 Role<\/span><\/strong><\/h4>\n<\/td>\n<\/tr>\n

    \u00a0 \u00a0 secretId<\/span><\/td>\n\u00a0 \u00a0 “mobile-app-v1” \u2014 server looks up which secret to use (rotation)<\/span><\/td>\n<\/tr>\n
    \u00a0 \u00a0 signedHeaderBlock<\/span><\/td>\n\u00a0 \u00a0 Headers bound into the signature, same format on both sides<\/span><\/td>\n<\/tr>\n
    \u00a0 \u00a0 bodyHex<\/span><\/td>\n\u00a0 \u00a0 sha256Hex(bodyStr) \u2014 hash of the sorted, stringified body<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
    \n

    How to call signOutgoingRequest<\/h2>\n

    Hook it into your HTTP client request interceptor after headers and body are ready:<\/p>\n

    import axios from “axios”;<\/span><\/strong>
    \nimport { signOutgoingRequest } from “.\/requestSigning”;<\/span><\/strong><\/p>\n

    const api = axios.create({<\/span><\/strong>
    \nbaseURL: “https:\/\/api.example.com”,<\/span><\/strong>
    \n});<\/span><\/strong><\/p>\n

    api.interceptors.request.use(<\/span><\/strong>
    \n(request) => {<\/span><\/strong>
    \nrequest.headers = request.headers ?? {};<\/span><\/strong>
    \nrequest.headers[“Content-Type”] = “application\/json”;<\/span><\/strong><\/p>\n

    signOutgoingRequest(request, sharedSecret); \/\/ adds x-request-time + x-request-signature<\/span><\/strong><\/p>\n

    return request;<\/span><\/strong>
    \n},<\/span><\/strong>
    \n(error) => Promise.reject(error),<\/span><\/strong>
    \n);<\/span><\/strong><\/p>\n

    await api.post(“\/api\/v1\/orders”, { itemId: “123”, qty: 2 });<\/span><\/strong><\/p>\n

    One-off:<\/p>\n

    const request = {<\/span><\/strong>
    \nmethod: “post”,<\/span><\/strong>
    \nurl: “\/api\/v1\/orders”,<\/span><\/strong>
    \ndata: { itemId: “123”, qty: 2 },<\/span><\/strong>
    \nheaders: {},<\/span><\/strong>
    \n};<\/span><\/strong><\/p>\n

    signOutgoingRequest(request, sharedSecret);<\/span><\/strong>
    \nawait api.request(request);<\/span><\/strong><\/p>\n\n\n\n\n\n
    \n

    \u00a0 \u00a0 Argument<\/strong><\/span><\/h4>\n<\/td>\n

    		\n

    \u00a0 \u00a0 Meaning<\/strong><\/span><\/h4>\n<\/td>\n<\/tr>\n

    \u00a0 \u00a0 request<\/span><\/td>\n\u00a0 \u00a0 Needs method, url, data, headers<\/span><\/td>\n<\/tr>\n
    \u00a0 \u00a0 sharedSecret<\/span><\/td>\n\u00a0 \u00a0 From openssl rand -hex 32 (or secrets store). Empty \u2192 request left unsigned<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    Headers set on success:<\/p>\n

      \n
    • x-request-time \u2014 same value inside the canonical string<\/li>\n
    • x-request-signature \u2014 hex HMAC of the canonical string<\/li>\n<\/ul>\n

      Use whatever header names your backend defines.<\/p>\n

      \n

      Sort the body before hashing<\/h2>\n

      JSON key order is not guaranteed:<\/p>\n

      {“b”:1,”a”:2} vs {“a”:2,”b”:1}<\/span><\/strong><\/p>\n

      Same meaning, different bytes \u2192 different bodyHex \u2192 signature mismatch.<\/p>\n

      Body sort fixes it:<\/strong> both sides run the same key-order pass (sortBodyKeys) before JSON.stringify and sha256Hex. Send that sorted body on the wire so what you transmit matches what you signed.<\/p>\n

      \n

      Challenges I faced<\/h2>\n

      Canonical strings did not match
      \nEven with the correct secret, signatures failed until both sides built the exact same string.<\/p>\n

      Common causes:<\/p>\n

        \n
      • Field order differs (timestamp before path on one side)<\/li>\n
      • Different newlines \/ separators<\/li>\n
      • Method casing (post vs POST)<\/li>\n
      • Path shape (\/api\/foo vs full URL vs trailing slash)<\/li>\n
      • Empty body as “” vs “{}” vs omitted<\/li>\n
      • Body hashed before sort on one side, after sort on the other<\/li>\n<\/ul>\n

        Fix: in non-prod, log the full canonical string (or its hash) on client and server and diff them.<\/p>\n

        Signature still wrong when \u201clogic looks fine\u201d<\/h4>\n

        Usually the message encoding differs, not the crypto:<\/p>\n

          \n
        • Algorithm (sha256) and digest form (hex vs base64)<\/li>\n
        • Secret as UTF-8 string vs raw bytes<\/li>\n
        • Timestamp as string vs number<\/li>\n
        • Header block casing \/ trimming<\/li>\n<\/ul>\n

          Sequence is the protocol<\/h4>\n

          If the backend expects:<\/p>\n

          METHOD \\n PATH \\n TIMESTAMP \\n …<\/span><\/strong><\/p>\n

          and the client sends:<\/p>\n

          METHOD \\n TIMESTAMP \\n PATH \\n …<\/span><\/strong><\/p>\n

          it will never verify. HMAC will not \u201cfigure out\u201d order \u2014 you must keep the same sequence as the backend (or document a shared sort both sides apply).<\/p>\n

          \n

          Best practice: mirror the backend<\/p>\n

          Treat the canonical format as a shared protocol \u2014 not a client-only convenience.<\/p>\n\n\n\n\n\n\n
          \n

          \u00a0 \u00a0 Do<\/span><\/h4>\n<\/td>\n

          		\n

          \u00a0 \u00a0 Why<\/span><\/h4>\n<\/td>\n<\/tr>\n

          \u00a0 \u00a0 Same fields, same order, same separators<\/span><\/td>\n\u00a0 \u00a0 HMAC is order-sensitive<\/span><\/td>\n<\/tr>\n
          \u00a0 \u00a0 Sort body keys on both sides<\/span><\/td>\n\u00a0 \u00a0 Avoids JSON key-order drift<\/span><\/td>\n<\/tr>\n
          \u00a0 \u00a0 Stabilize only the headers you sign<\/span><\/td>\n\u00a0 \u00a0 Keeps signedHeaderBlock identical<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

          Do not invent a friendlier order on the client. Align with BE first; any body-sort step must run the same way on both sides.<\/p>\n

          \n

          Checklist<\/h2>\n
            \n
          1. One written canonicalization spec for mobile, web, and API.<\/li>\n
          2. Bind many request dimensions (method, path, time, secret id, headers, body hash).<\/li>\n
          3. Strong secret via openssl rand -hex 32; rotate with secretId.<\/li>\n
          4. Server rejects old timestamps (e.g. \u00b12\u20135 minutes).<\/li>\n
          5. Hash the body (bodyHex); do not dump huge payloads raw into HMAC.<\/li>\n
          6. Constant-time signature compare on the server.<\/li>\n
          7. Never log secrets; debug canonical strings only in non-prod.<\/li>\n
          8. Fail closed if signing fails when the API requires HMAC.<\/li>\n
          9. Version the scheme if field order ever changes.<\/li>\n
          10. Golden-vector tests: fixed inputs \u2192 expected signature on both sides.<\/li>\n<\/ol>\n
            \n

            Mental model<\/h2>\n

            openssl rand -hex 32 \u2192 shared secret<\/span><\/strong>
            \nsort body + pick fields \u2192 canonical string (fixed order)<\/span><\/strong>
            \nHMAC-SHA256 \u2192 x-request-signature<\/span><\/strong>
            \nserver repeats \u2192 accept or 401<\/span><\/strong><\/p>\n

            HMAC itself is simple. The hard part is discipline: identical inputs, identical order, identical encoding. Get the canonical string right on both sides, and request signing becomes boring \u2014 in the best way.<\/p>\n","protected":false},"excerpt":{"rendered":"

            Introduction HMAC request signing proves two things to your backend: the caller knows a shared secret, and the request was not altered after it was signed. It is not encryption \u2014 the body stays readable \u2014 but it is a strong, lightweight integrity and authenticity check for mobile APIs. What is HMAC? HMAC (Hash-based Message […]<\/p>\n","protected":false},"author":1816,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":4},"categories":[5881],"tags":[8746,1303,8570,5853],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/80772"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/1816"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=80772"}],"version-history":[{"count":2,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/80772\/revisions"}],"predecessor-version":[{"id":80972,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/80772\/revisions\/80972"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=80772"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=80772"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=80772"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}