Skip to main content

Overview

Bring Your Own Auth (BYOA) lets you authenticate your own users to EkaCare agents without an OIDC flow. Your backend builds a short-lived token containing the user’s identity, secures it with your shared secret, and sends it to EkaCare — which looks up your secret by its Key ID, verifies the token, and trusts the claims inside. BYOA supports two token formats:
  • Signed JWT (JWS)the default. The claims are signed (HS256) with your shared secret. The payload is readable but tamper-proof. Lighter and simpler — use this unless you have a specific reason not to.
  • Encrypted JWE — an optional, heavier alternative where the claims are encrypted. Use it only when the token travels somewhere it could be logged or inspected (e.g. a URL query parameter) and carries genuinely sensitive data. See Encrypted Token (JWE).
Both formats use the same shared secret and Key ID from the same BYOA credential. The kid header tells EkaCare which secret to use; the token format (signed vs encrypted) is detected automatically.
Use BYOA when your client has no OIDC/OAuth flow and you want to pass user data (mobile, name, etc.) to EkaCare from your own backend.

JWT or JWE?

Default to a signed JWT. Reach for JWE only when both of these are true:
  1. The token is sent somewhere observable — most commonly a URL query parameter (which can be logged by proxies, servers, and browser history), rather than a header or request body, and
  2. The payload contains highly sensitive information that must not be readable in transit.
If you’re passing the token in a header, request body, or the widget’s auth-token attribute — which is the normal case — use a JWT. It’s lighter, easier to debug, and just as secure against tampering.

Before You Begin

Create a BYOA credential in the Eka Developer Console. You will need:
  • Key ID — the public identifier for your credential (e.g. byoa_xxxxxxxxxxxxxxxx); goes in the token’s kid header.
  • Shared secret — used to sign (JWT) or encrypt (JWE) the token. Shown only once at creation.
  • Issuer — the issuer URL you registered on the credential; the token’s iss claim must match it exactly.
The shared secret is shown only once. Store it securely on your backend and never expose it in client-side code. If it is lost or leaked, revoke the credential and create a new one.

How It Works

1

Create a credential

In the Eka Developer Console (BYOA → Create) you get a Key ID and a shared secret. The secret is shown only once — copy it immediately.
2

Build the claims

On your backend, assemble the user’s identity claims (see Token Structure).
3

Sign as a JWT

Sign the claims with your shared secret using HS256, with the protected header kid set to your Key ID. (Or, for the sensitive-query-param case, encrypt as a JWE.)
4

Send it

Hand the token to your embedded MedAssist widget — via the auth-token attribute or EkaMedAssist.init({ authToken }). See Send the Token.
5

EkaCare verifies

EkaCare looks up your secret and registered issuer by the kid, verifies the signature, and trusts the verified claims.

Token Structure

The x-auth-token is a compact JWT (JWS) with a signed header and a payload of claims.
  • kid — your credential’s Key ID.
  • algHS256 (HMAC-SHA256; the shared secret is the signing key).
  • typJWT.

Payload claims

string
required
Your issuer — must exactly match the issuer registered on your credential.
string
required
Intended audience. Always https://eka.care.
string
Subject — your stable user identifier (partner user id). Leave it empty ("") if you identify users only by mobile number (e.g. WhatsApp), where the mobile claim is the identifier instead.
string
The user’s mobile number, with country code.
number
required
Issued-at time, in epoch seconds (UTC).
number
required
Expiry time, in epoch seconds. Keep it short — iat + 300 (about 5 minutes).
string
Recommended. A unique ID per request so EkaCare can reject replays of the same token.
Example payload:
The shared secret is a base64url-encoded 32-byte key. Decode it to 32 raw bytes before using it as the HS256 HMAC signing key.

Generate the Token

Build the claims and sign them as a JWT with your shared secret (HS256, header kid). The shared secret is base64url-decoded to a 32-byte key.

Send the Token

The MedAssist widget is EkaCare’s embeddable chat widget. Copy its embed snippet from your agent’s Widget tab in the Developer Console (or see the widget quickstart), then add the token to it. The Widget tab in the EkaCare Developer Console, showing the embed code to copy There are two ways to pass the token:
  • Custom element — set the auth-token attribute on the <eka-medassist-widget> element. Best when you can render the token into the page server-side. See the widget quickstart.
  • JavaScript — pass authToken to EkaMedAssist.init(). Best when the token is dynamic (e.g. minted per logged-in user at runtime). See the JavaScript API.

How EkaCare Verifies

When EkaCare receives the token, it:
  1. Reads the kid from the token header and looks up the matching shared secret and registered issuer.
  2. Verifies the JWT signature with your secret (or decrypts it, if it’s a JWE).
  3. Verifies the claims — iss matches the registered issuer, aud is https://eka.care, and iat and exp are within the allowed window. If you include a jti, it must not have been seen before (replay protection).
If any check fails, the request is rejected.

Encrypted Token (JWE)

JWE is an optional alternative to the default signed JWT. It’s heavier than a JWT. Only use it when the token is sent somewhere observable — most commonly a URL query parameter (which can be logged by proxies, servers, and browser history) — and its payload holds highly sensitive information that must not be readable in transit. Otherwise, use a signed JWT.
A JWE carries the same claims as the JWT above (Token Structure) and uses the same Key ID and shared secret — the payload is encrypted instead of signed.

Header

  • kid — your credential’s Key ID.
  • algdir (the shared secret is used directly as the encryption key).
  • encA256GCM (content encryption).
The shared secret is a base64url-encoded 32-byte key. Decode it to 32 raw bytes before using it as the A256GCM content-encryption key.

Generate the JWE

Build the claims, encrypt them as a JWE with your shared secret (alg: dir, enc: A256GCM, header kid), and serialize to compact form. The shared secret is base64url-decoded to a 32-byte key.
EkaCare detects the JWE format automatically, looks up your secret by kid, decrypts it, and verifies the same claims as a JWT.

Best Practices

  • Generate tokens server-side only — never ship the shared secret to a browser or mobile app.
  • Prefer a signed JWT; reach for JWE only for sensitive data on query parameters.
  • Keep exp short (~5 minutes) and use a fresh jti for every request.
  • Rotate by revoking the credential and creating a new one, then update your agents to the new Key ID.