Authentication overview

Tyk's API Gateway functions as an enforcement point for API authentication, verifying the identity of clients attempting to access managed APIs. This process is integral to securing API endpoints, preventing unauthorized access, and enabling rate limiting or quota enforcement based on client identity. Tyk integrates various authentication protocols and mechanisms directly into its gateway, allowing developers and administrators to configure access controls declaratively within API definitions.

The gateway processes incoming requests, extracts authentication credentials (e.g., API keys, OAuth tokens), and validates them against configured policies. If the credentials are valid and authorized, the request is permitted to proceed to the upstream service. If invalid, the gateway will reject the request, typically returning an HTTP 401 Unauthorized or 403 Forbidden status code. Tyk's approach emphasizes flexibility, enabling different authentication methods to be applied to different APIs or even different endpoints within the same API, based on specific security and operational requirements. Configuration is typically managed through the Tyk Dashboard or via the Tyk Gateway API, which allows for programmatic management of API keys, policies, and other access controls.

Supported authentication methods

Tyk supports a range of authentication methods, catering to various use cases from simple client identification to complex federated identity scenarios. The choice of method depends on factors such as the nature of the client, the sensitivity of the data, and integration with existing identity providers.

Method When to Use Security Level
API Keys Simple client identification, rate limiting, basic access control. Suitable for internal services or partners with less stringent security needs. Basic to Moderate. Relies on key secrecy.
OAuth 2.0 Delegated authorization for third-party applications. Ideal for consumer-facing APIs where users grant limited access without sharing credentials. Supports various OAuth 2.0 grant types such as Authorization Code, Client Credentials, and Implicit. High. Token-based, short-lived access.
JWT (JSON Web Tokens) Stateless authentication and information exchange. Useful for microservices architectures and situations where identity information needs to be securely transmitted between services. Can be used for fine-grained authorization. High. Cryptographically signed, can be encrypted.
OpenID Connect Identity layer on top of OAuth 2.0. Used for user authentication and obtaining basic profile information. Integrates with identity providers like Google, Azure AD, Okta. Very High. Provides identity verification and user profile information in addition to authorization.
Mutual TLS (mTLS) Strongest authentication for service-to-service communication. Both client and server verify each other's digital certificates. Primarily for highly sensitive internal APIs or B2B integrations requiring strong identity assurance. Highest. Bi-directional certificate validation.
Basic Auth Legacy systems, simple browser-based access. Not recommended for new applications due to clear-text credential transmission over unencrypted channels (though HTTPS mitigates this). Low to Moderate (with HTTPS).
No Auth Public APIs, health checks, unauthenticated endpoints. None.

Getting your credentials

The process for obtaining and managing credentials in Tyk varies based on the chosen authentication method:

API Keys

  1. Tyk Dashboard: Navigate to the 'Keys' section. You can create new API keys, associate them with policies (which define access rights, rate limits, and quotas), and configure their expiration. Each key is a unique string.
  2. Tyk Gateway API: Programmatically create and manage keys by making API calls to the Tyk Gateway's Key Management endpoint. This is useful for automating key provision and integration with external systems.
  3. Developer Portal: If enabled, end-users or developers can sign up for the Developer Portal and generate their own API keys, often tied to specific application registrations.

OAuth 2.0 and OpenID Connect

For OAuth 2.0 and OpenID Connect, Tyk acts as an OAuth provider or relies on an external Identity Provider (IdP). The credentials typically involve:

  1. Client ID and Client Secret: These are registered within Tyk (if Tyk is the OAuth provider) or with an external IdP. Applications use these to identify themselves when requesting access tokens.
  2. Access Tokens: Obtained by the client from Tyk or the IdP after successful authorization. These are short-lived and used to access protected resources. Tyk validates these tokens.
  3. Refresh Tokens: (Optional) Used to obtain new access tokens without re-authenticating the user.

Configuration involves defining an OAuth client within Tyk's API definition, specifying the grant types, redirect URIs, and linking to an upstream IdP if applicable. Tyk can also serve as a complete OAuth 2.0 Provider, managing client registration and token issuance directly.

JWT and Mutual TLS

  • JWT: Tyk can be configured to validate JWTs issued by external identity providers. This involves specifying the expected issuer, audience, and the public key or certificate used to sign the JWT. Tyk does not issue JWTs directly for client authentication but validates them.
  • Mutual TLS: Requires clients to present a valid X.509 certificate signed by a trusted Certificate Authority (CA). The CA certificates are configured within Tyk's gateway settings, and Tyk performs certificate validation during the TLS handshake. This is a highly secure method for machine-to-machine communication.

Authenticated request example

The method of including credentials in an API request depends on the chosen authentication scheme.

Example 1: API Key Authentication

When using API key authentication, the key is typically sent in a custom HTTP header (e.g., x-tyk-api-key) or as a query parameter. Tyk's default header is x-tyk-api-key, but this can be customized in the API definition.

curl -X GET \
  https://your-tyk-gateway.com/your-api/resource \
  -H 'x-tyk-api-key: YOUR_API_KEY_HERE' \
  -H 'Content-Type: application/json'

Replace YOUR_API_KEY_HERE with an actual API key generated in the Tyk Dashboard or via the Gateway API.

Example 2: OAuth 2.0 Access Token Authentication

For OAuth 2.0, an access token is typically included in the Authorization header using the Bearer scheme, as specified by RFC 6750.

curl -X GET \
  https://your-tyk-gateway.com/your-api/resource \
  -H 'Authorization: Bearer YOUR_ACCESS_TOKEN_HERE' \
  -H 'Content-Type: application/json'

Here, YOUR_ACCESS_TOKEN_HERE would be the token obtained from an OAuth flow. Tyk validates this token against its configured OAuth provider settings.

Security best practices

Implementing authentication with Tyk requires adherence to general API security best practices to protect both the APIs and the data they expose.

  • Use HTTPS/TLS Everywhere: Always ensure all API communication occurs over HTTPS. This encrypts data in transit, protecting credentials and sensitive information from eavesdropping. Tyk automatically enforces HTTPS for its endpoints.
  • Principle of Least Privilege: Grant only the necessary permissions to API keys or OAuth clients. Use Tyk Policies to define granular access controls, restricting access to specific endpoints, HTTP methods, or even applying rate limits.
  • Rotate Credentials Regularly: Implement a strategy for regular rotation of API keys, client secrets, and other static credentials. This reduces the window of opportunity for compromised credentials to be exploited.
  • Strong API Key Management: Treat API keys as sensitive secrets. Do not hardcode them in client-side code, commit them to version control systems, or expose them in client-side applications. Use environment variables or secure credential stores.
  • Short-Lived Tokens (OAuth/JWT): Configure OAuth access tokens and JWTs with short expiration times. This minimizes the impact of a token compromise. Use refresh tokens (if applicable) for obtaining new access tokens without user re-authentication, but secure refresh tokens equally stringently.
  • Input Validation and Sanitization: While primarily an application-level concern, ensure that any data passed through the API gateway is validated and sanitized to prevent injection attacks and other vulnerabilities. Tyk can assist with basic payload validation.
  • Monitoring and Logging: Enable comprehensive logging in Tyk to monitor authentication attempts, failures, and access patterns. Integrate Tyk's logs with a centralized security information and event management (SIEM) system for anomaly detection and auditing.
  • Implement Rate Limiting and Throttling: Use Tyk's built-in rate limiting and quota management features to prevent brute-force attacks on authentication endpoints and protect backend services from overload.
  • Secure Tyk Itself: Secure the Tyk Dashboard, Gateway, and Redis instances. Apply network segmentation, strong passwords, and access controls to Tyk's administration interfaces and underlying infrastructure. Regularly update Tyk components to the latest security patches.
  • Consider Multi-Factor Authentication (MFA) for Admin Access: For Tyk Dashboard administrators, implement MFA to add an extra layer of security beyond passwords.
  • Error Handling: Design API error responses to be generic, avoiding the disclosure of sensitive information such as specific authentication failure reasons that could aid attackers.