Forem: Fung

Testing HMAC Signatures Online — A Free Developer Tool

Fung — Wed, 08 Oct 2025 16:21:39 +0000

APIs often rely on HMAC signatures to verify the authenticity and integrity of requests.
Whether you’re validating webhooks, securing IoT messages, or signing API payloads, it’s crucial to confirm that your HMAC implementation works correctly — and that both client and server generate the same signature.

That’s where a free testing tool helps.

🔐 What Is an HMAC Signature?

An HMAC (Hash-based Message Authentication Code) is a unique signature generated by hashing a message with a secret key.
If the message changes or the key is incorrect, the signature won’t match — protecting your API from tampering or replay attacks.

Example:

HMAC = hash(secret_key + message)

Common algorithms: SHA-256, SHA-1, SHA-512

🧮 Why You Need to Test HMAC Signatures

When integrating APIs, mismatched HMAC signatures are among the most common debugging issues.
You might face:

Incorrect encoding (UTF-8 vs ASCII)
Mismatched algorithms (SHA1 vs SHA256)
Differences in message formatting
Missing newline characters or whitespace

Testing with a live HMAC tool helps quickly isolate these problems before they break production code.

🧰 Free Tool: HMAC Signature Generator & Verifier

You can instantly generate or verify HMAC signatures using this free tool:

👉 HMAC Signature Generator & Verifier — by Authgear

Features:

Supports SHA-1, SHA-256, and SHA-512
“Generate” or “Verify” modes
Copy-to-clipboard output
Real-time hash calculation
No account or API key required

How to Use It:

Paste your message.
Enter your secret key.
Choose the hash algorithm (e.g., SHA-256).
Click Generate to get your signature — or switch to Verify mode to compare an existing one.

It’s a simple way to confirm that your backend code is producing the same HMAC value you expect.

🧑‍💻 Quick Example in Node.js

const crypto = require('crypto');
const message = 'Hello from Authgear';
const secret = 'mysecretkey';

const signature = crypto
  .createHmac('sha256', secret)
  .update(message)
  .digest('hex');

console.log('Generated HMAC:', signature);

You can paste your message and secret into the Authgear HMAC tool to verify the result instantly.

🌐 Why Developers Use HMAC

Lightweight and fast
Works offline (no tokens or external verification)
Easy to implement in any language
Still one of the most secure message verification methods in 2025

JWE vs JWT — Side-by-Side for Developers

Fung — Fri, 15 Aug 2025 08:30:00 +0000

TL;DR:

JWT = signed, readable payload (integrity).

JWE = encrypted, hidden payload (integrity + confidentiality).

This is a quick, practical breakdown with examples and a comparison table you can skim in under 3 minutes.

JWT (JSON Web Token) in a nutshell

Structure: header.payload.signature
Signed to prevent tampering, but not encrypted — anyone with the token can read the payload.
Great for auth claims, sessions, API access control.

Example (shortened):

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

JWE (JSON Web Encryption) in a nutshell

Structure: protectedHeader.encryptedKey.iv.ciphertext.tag
Encrypted — only intended recipients can read the payload.
Great for transmitting sensitive data (PII, financial info, secrets).

Example (shortened):

eyJhbGciOiJSU...encryptedKey...iv...ciphertext...tag

JWE vs JWT — Quick Comparison

Feature	JWT	JWE
Data Protection	Signed only – payload visible	Encrypted – payload hidden
Primary Use	Authentication & claims verification	Secure data transmission
Performance	Faster, smaller size	Slower, larger size
Visibility	Anyone can read payload	Only recipients can decrypt
Complexity	Easier to implement	More complex setup
Security Level	Protects integrity	Protects integrity and confidentiality

When to use which

Choose JWT when you only need integrity (no tampering) and payload visibility is acceptable.
Choose JWE when you also need confidentiality — the payload must remain private.

Bonus: structures at a glance

JWT parts:

Header: alg, kid, typ
Payload: claims
Signature: verifies integrity

JWE parts:

Protected Header: alg, enc, kid
Encrypted Key: content-encryption key for recipient
IV: initialization vector
Ciphertext: encrypted payload
Tag: authentication tag

Tools for working with tokens

Need to generate keys or convert PEM → JWK for testing JWT/JWE?

Try this JWK Generator

Read the full guide

For deeper explanations, examples, and best practices, read the original post on Authgear:

https://www.authgear.com/post/jwe-vs-jwt

What is JWKS? JSON Web Key Set — Short Guide

Fung — Thu, 14 Aug 2025 13:16:54 +0000

If you work with JWTs, OAuth, or any token-based authentication, you’ve probably seen the term JWKS. So — what is JWKS and why does it matter? In short: a JWKS (JSON Web Key Set) is a standardized JSON document that publishes one or more public keys (JWKs) so clients and APIs can verify signatures or perform encryption. This guide explains JWKS in plain language, shows the JWK format with examples, covers the jwks uri pattern, and gives practical tips for creating and managing JWKS in production.

Understanding JSON Web Keys (JWK) and JWKS

A JSON Web Key (JWK) is a JSON object that represents a cryptographic key — for example, an RSA public key or an EC key. Key fields include kty (key type), kid (key id), use (intended use), alg (algorithm), and key material fields like n/e for RSA or x/y for EC.

A JWKS is simply a JSON object with a keys array that bundles multiple JWKs:

{
  "keys": [
    {
      "kty": "RSA",
      "kid": "2023-01-key-1",
      "use": "sig",
      "alg": "RS256",
      "n": "...", 
      "e": "AQAB"
    }
  ]
}

Why this matters: services that issue tokens publish a JWKS so other services (APIs, clients) can automatically fetch the public keys they need to verify token signatures or encrypt payloads. The JWKS standard makes this machine-readable and interoperable across libraries.

How JWKS Works in Authentication & APIs

Typical flow in an API ecosystem:

Issuer publishes a JWKS at a stable URL (the jwks_uri).
Clients or resource servers fetch the JWKS and cache it.
When a JWT arrives, the kid in the token header identifies which JWK to use.
The client finds the matching JWK inside the JWKS and uses it to verify the token signature or perform encryption-related steps.

This pattern decouples key rotation from deployments: when you roll keys, you update the JWKS; consuming services pick up updated public keys without redeploying code. For JWEs (encrypted tokens), the JWKS can provide public keys for encryption as well.

JWKS URI: How to Find and Use It

Many identity providers expose a discovery document — often at /.well-known/openid-configuration — which contains a jwks_uri field that points to the JWKS location:‍

{
  "issuer": "https://idp.example.com",
  "jwks_uri": "https://idp.example.com/.well-known/jwks.json"
}

‍How to use the jwks_uri:

Configure your OIDC/OAuth client library to read the discovery document or directly point it to the jwks_uri.
Libraries will fetch and cache the JWKS, matching the kid in incoming JWTs to the correct JWK.
Implement a refresh strategy (e.g., periodic refresh or refresh on verification failures) so your service handles key rotation smoothly.
Tip: Always serve JWKS over HTTPS and include stable kid values for easier rotation handling.

JWK Format Explained (with Example)

A JWK contains a standardized set of fields. Here’s a more complete RSA public key example:

{
  "kty": "RSA",
  "kid": "2011-04-29",
  "use": "sig",
  "alg": "RS256",
  "n": "oahUI...base64url-modulus...",
  "e": "AQAB"
}

Field breakdown:

kty — key type (e.g., RSA, EC, oct)
kid — key ID used to select keys in a JWKS
use — intended use: sig for signature verification, enc for encryption
alg — algorithm (e.g., RS256, ES256)
n, e (RSA) or x, y, crv (EC) — the key material in base64url form

Full JWKS example with two keys:

{
  "keys":[
    {
      "kty":"RSA","kid":"rsa1","use":"sig","alg":"RS256","n":"...","e":"AQAB"
    },
    {
      "kty":"EC","kid":"ec1","use":"enc","alg":"ECDH-ES","crv":"P-256","x":"...","y":"..."
    }
  ]
}

Including use and alg fields helps clients quickly determine whether a key is suitable for signature verification or encryption.

PEM and converting to JWK

PEM (Privacy-Enhanced Mail) is a very common format for storing keys and certificates. It’s base64-encoded DER data wrapped in human-readable header/footer lines such as -----BEGIN PUBLIC KEY----- and -----END PUBLIC KEY-----. You’ll often see PEM files with extensions like .pem, .crt, or .key.

If you need to use a PEM key with a JWKS workflow, the usual step is to extract the public key from the PEM and convert that public key into a JWK. For RSA keys you can extract the public PEM like this:

openssl rsa -in private.pem -pubout -out public.pem

For EC keys, the extraction looks similar:

openssl ec -in key.pem -pubout -out public.pem

Once you have the public PEM, convert it to a JWK using a JOSE library (node-jose, python-jose, etc.) or a conversion tool. The conversion produces the JWK fields your JWKS needs — for example kty, n/e (RSA) or x/y/crv (EC).

If you want a quick, UI-driven option, the Authgear JWK Generator can convert PEM public keys into correctly formatted JWK objects (RSA/EC) so you can drop them straight into your JWKS.

Security note: never publish private PEM material in a JWKS. Only include public key material, always serve your JWKS over HTTPS, and follow a safe key-rotation strategy.

Creating and Managing JWKS for Your Application

Generating keys: You can create JWKs with various libraries (node-jose, python-jose, OpenSSL + converters) or use a purpose-built tool. If you want a quick, standards-compliant way to create JWKs or convert existing PEM keys into JWK format, try the Authgear JWK Generator — it outputs RSA/EC key pairs and can convert PEM public keys into JWK format, ready for development and testing.

Publishing a JWKS:

Host the JWKS JSON at a stable HTTPS endpoint (e.g., https://auth.example.com/.well-known/jwks.json).
Only include public key material; never publish private keys.
Assign kid values and add new keys before rotating old ones.

Rotation strategy:

Generate new key pair and add the public JWK to the JWKS with a new kid.
Update the issuer to sign tokens with the new private key.
Keep the old public JWK in the JWKS for a grace period to allow clients to validate existing tokens.
Remove the old JWK once tokens signed with it are expired.

Security best practices:

Serve JWKS over HTTPS.
Cache the JWKS but refresh on verification errors.
Limit JWKS to only the keys you actively use.
Monitor for failed verifications that might signal a missing or rotated key.

Common Questions About JWKS (FAQ)

What is JWKS used for?

JWKS is used to publish public keys that clients and APIs can fetch to verify JWT signatures or obtain public keys for encryption workflows — enabling dynamic, interoperable key distribution.

Is a JWKS file public or private?

A JWKS is typically public — it contains public keys only. Private keys must stay secure on the issuer’s side and should never be included.

How do I generate a JWK?

You can generate JWKs via libraries (OpenSSL → convert to JWK, or use JOSE libraries) or use a generator tool like Authgear’s JWK Generator to quickly produce JWK-formatted keys for testing or staging.

Relationship to JWT and JWE

JWT (signed tokens): JWTs include a kid in the header that points to a JWK in a JWKS so recipients can verify signatures using the corresponding public key.
JWE (encrypted tokens): JWKS can also publish public keys used to encrypt payloads or derive shared keys for decryption on the recipient side.

You don’t need deep knowledge of JWT/JWE to use JWKS — just remember JWKS is the standard way to distribute public keys that make JWT signature verification and JWE encryption interoperable.

Conclusion

A JWKS (JSON Web Key Set) is a small but crucial piece of modern token-based security: it standardizes how public keys (JWKs) are published and fetched via a jwks_uri, enabling seamless verification and encryption across services. Use correct JWK format, host your JWKS securely, implement a rotation strategy, and consider using tools like the Authgear JWK Generator to speed up development, convert PEM public keys, and simplify testing.

For the full guide with extended examples, code snippets, and best practices, read the canonical article on Authgear:
https://www.authgear.com/post/what-is-jwks

SSO Simplified: Enhancing Security and User Experience

Fung — Mon, 02 Sep 2024 05:27:52 +0000

Single Sign-On (SSO) has become a cornerstone of modern digital authentication strategies. In essence, SSO allows users to access multiple applications and services with a single set of credentials, streamlining the user experience and enhancing security. For IT managers and technicians, implementing SSO effectively can significantly reduce password fatigue, minimize security risks, and improve overall productivity.

This handbook article aims to provide a deep dive into SSO technologies, exploring various implementation scenarios, underlying mechanisms, and best practices. By the end of this guide, you'll be equipped with the knowledge to make informed decisions about SSO deployment in your organization.

1. Scenarios Where SSO is Needed

1.1 Multi-app Ecosystem

Large tech companies often operate diverse portfolios of applications and services. SSO plays a crucial role in unifying these ecosystems:

Meta: Facebook, Instagram, Messenger, and Threads form a tightly integrated social media ecosystem. Users can seamlessly switch between these platforms without re-authenticating, enhancing engagement and cross-platform interactions.
Google: The suite including Google Photos, Drive, Maps, and Home devices showcases how SSO can span both web and IoT environments. A single Google account provides access to a vast array of services, from productivity tools to smart home controls.
Uber: By unifying Uber ride-hailing, UberEats food delivery, and the Uber Drivers app under a single authentication system, the company provides a cohesive experience for both customers and service providers.

In these ecosystems, SSO not only enhances user experience but also allows for more effective data sharing and personalization across services, while maintaining robust security protocols, even if the apps were all built by completely different teams.

1.2 Spin-off Apps and Campaigns

Enterprises frequently launch new initiatives that require rapid development and deployment. This often includes spin-off projects, and prototype testing of new product concepts. In such cases, Single Sign-On (SSO) can be a crucial tool.

For marketing campaigns requiring quick web apps, SSO allows these temporary applications to securely use existing user bases. SSO also streamlines user onboarding for new ventures by tapping into the parent company’s user pool and facilitates prototype testing with a subset of existing users without creating new authentication systems.

Sometimes, the development team of the core app may be too busy to respond quickly to requests for new initiatives, such as a web app for a marketing campaign. Having an SSO infrastructure in place can empower a small development and design team to iterate rapidly.

By implementing SSO, organizations can maintain agility in launching new initiatives while ensuring that user data remains protected and consistent across all touchpoints.

1.3 Super Apps with Mini Programs

The concept of super apps, popularized in Asian markets, is gaining traction globally, with some popular examples including:

LINE/KakaoTalk: These super apps incorporate messaging, social media, and a vast ecosystem of mini-programs, all accessible through a single login.
Gojek: In Southeast Asia, Gojek offers ride-hailing, food delivery, news, and financial services within a single app.

Super apps can also be found within enterprise environments, where they offer significant advantages:

Corporate Portals: Instead of asking staff to install multiple different apps, an enterprise may package various internal tools into a single mobile app. This super app can include systems like HR, inventory management, and communication platforms, all built by different developers or business units.
Field Service Apps: Companies with mobile workforces, such as maintenance or IT, can bundle multiple tools (scheduling, invoicing, knowledge bases) into one app with SSO. This approach provides employees with seamless access to all necessary resources in one place.

In both cases, services must be accessible on mobile platforms and web browsers. Delivering these services as web apps is cost-effective and ensures they are always up-to-date. However, implementing SSO in super apps presents unique challenges, particularly in managing session states across different mini-programs or web views.

A secure SSO mechanism helps manage sessions across the app suite, allowing for smooth transitions between services while maintaining strict security boundaries. IT professionals must ensure seamless integration between various services to provide an efficient user experience and uphold high security standards.

1.4 App-to-App Authentication

App-to-app (app2app) authentication is becoming increasingly important in mobile ecosystems, as it offers a simpler and faster flow for authentication when the user has already installed and logged into another recognized app on their mobile device. Here are some key use cases:

Financial Services: Banking apps can authorize fintech apps to access account information, streamlining processes like budgeting or investment management.

This integration allows users to seamlessly manage their finances across multiple platforms within a single application.

Implementing app2app authentication requires careful consideration of security protocols, user consent mechanisms, and data sharing policies. IT managers must ensure compliance with regulations like GDPR or PSD2 when implementing these solutions.

2. How Sessions are Shared Between Services

2.1 Cookies

Cookie-based SSO is one of the most straightforward and essential methods for authenticating users in web applications. It offers several advantages such as:

Domain-Level Sharing: By configuring cookies at the root domain level (e.g., .example.com), all subdomains can access the same session information, making it easier to manage user sessions across multiple subdomains.
Secure and HttpOnly Flags: These flags enhance security by restricting client-side access to cookies and ensuring that they are only transmitted over secure channels.
SameSite Attribute: This attribute helps mitigate cross-site request forgery (CSRF) attacks by controlling how cookies are included with cross-site requests.

2.2 Redirect Flow

You tap "Login" in an app, and it whisks you away to a familiar login page in your browser. After entering your credentials, you're seamlessly transported back to the app, now fully logged in. This smooth back-and-forth dance is known as the "redirect flow" - a typical implementation of Single Sign-On (SSO) technology.

This seamless experience extends across multiple apps. When a new app redirects you to the same login page, you'll often find your session is still active. With just a quick "Continue" tap, you're in - no need to re-enter your credentials.

The redirect flow is crucial for implementing SSO in cross-platform applications and requires secure token exchange mechanisms such as:

OAuth 2.0 and OpenID Connect: These protocols standardize the authorization and authentication processes, allowing for secure token exchange.
State Parameter: This prevents CSRF attacks by ensuring the request's integrity throughout the redirect process.
PKCE (Proof Key for Code Exchange): An additional security layer for mobile and single-page applications to prevent interception of the authorization code.

Here’s an example flow:

User clicks "Login" in App A
App A redirects to centralized auth server with client_id and redirect_uri
User authenticates on auth server
Auth server redirects back to App A with an authorization code
App A exchanges code for access and refresh tokens
App A can now make authenticated API calls

Implementing this flow requires careful coordination between the client application, authorization server, and resource server to ensure secure token handling and validation.

2.3 Shared Container

Imagine this: You download the new shiny app Google just released, and it instantly opens to your personalized dashboard without asking you to log in or provide details. No email entry, no password prompt — just immediate access. Real-life magic.

This is where shared containers come in.

Shared containers provide a native SSO experience on mobile platforms:

iOS Keychain and App Groups: Allow secure sharing of credentials between apps from the same developer.
Android AccountManager: Provides a centralized registry of user credentials that can be securely accessed by authorized apps.

This example demonstrates how to securely store and retrieve authentication tokens using the iOS Keychain, which can be shared between apps from the same developer.

3. Choosing the Right SSO Approach

Selecting the appropriate SSO method depends on various factors:

Platform Diversity:
- Web-only: For non-SPA websites, consider cookie-based solutions. For other applications requiring web-specific SSO protocols you can consider using redirect flow.
- Mixed (Web and Mobile): Implement OAuth 2.0 with OpenID Connect for a standardized approach across platforms.
- Mobile-only: Utilize platform-specific shared containers or app2app authentication.
Security Requirements:
- High-security environments may require additional factors like biometrics or hardware tokens.
- Consider implementing FIDO2 standards for passwordless authentication.
User Experience:
- Evaluate the trade-off between security and convenience.
- Consider implementing step-up authentication for sensitive operations.
Regulatory Compliance:
- Ensure your SSO solution adheres to relevant standards (e.g., GDPR, HIPAA, PSD2).
- Implement appropriate consent and data sharing mechanisms.
Scalability:
- Choose solutions that can grow with your user base and application ecosystem.
- Consider cloud-based identity providers for easier management and scalability.

Taking a thoughtful approach to these considerations will not only enhance security but also streamline access across diverse platforms, ultimately supporting a seamless and efficient user experience.

Conclusion

Implementing SSO effectively requires a deep understanding of various technologies and careful consideration of your organization's specific needs. By leveraging the right combination of cookies, redirect flows, shared containers, and app2app authentication, you can create a seamless and secure authentication experience across your entire digital ecosystem.

As you move forward with your SSO implementation, remember to:

Regularly audit your authentication systems for security vulnerabilities.
Stay informed about emerging authentication standards and best practices.
Collect and analyze user feedback to continuously improve the login experience.
Plan for future expansion of your application ecosystem and how it will integrate with your SSO solution.

By following these guidelines and choosing the appropriate SSO methods for your use cases, you can significantly enhance both the security and usability of your organization's digital services.

This article is part of a multi-part handbook. If you're interested, follow for more upcoming posts about SSO or join our auth-oriented community