The Auth middleware protects your Gin routes by validating JWT tokens on every incoming request. It extracts the token from theDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/AndresGT/GoKit/llms.txt
Use this file to discover all available pages before exploring further.
Authorization: Bearer header or a token cookie, validates it using GoKit’s JWT package, and injects the user’s ID, role, and full claims into the Gin context. Unauthorized requests are aborted with a structured JSON error before they ever reach your handlers.
Import
Overview
When a request arrives, the middleware runs through the following steps:Skip check
If the request path matches any entry in
SkipPaths, the middleware calls c.Next() immediately — no token required.Token extraction
The configured
TokenExtractor reads the token string from the request. By default it checks the Authorization: Bearer <token> header first, then falls back to the token cookie.JWT validation
The token is validated via
jwt.Validate(). An invalid or expired token is logged at Security level and results in a 401 response.Claims validation
The middleware checks that the claims contain a non-nil
UserID and a non-empty Role. Missing claims return a 403 response.Usage
AuthConfig{} applies all defaults: DefaultTokenExtractor, the global logger, and no skip paths.
Configuration
Paths that bypass authentication entirely. Supports exact matches and wildcard prefixes — any entry ending with
* skips all paths that start with the prefix before the asterisk.A function that receives the Gin context and returns the raw JWT string. Defaults to
DefaultTokenExtractor. Set this to HeaderOnlyExtractor or CookieOnlyExtractor for stricter extraction, or provide your own function for custom schemes.Called when authentication fails. If
nil, the default handler returns a JSON body with {"error": "unauthorized"} (401) or {"error": "invalid claims"} (403) and aborts the request.The logger instance used for security and debug events. Falls back to the GoKit global logger when
nil.Built-in Token Extractors
GoKit ships three ready-to-use extractors:DefaultTokenExtractor
Checks
Authorization: Bearer <token> first, then falls back to the token cookie. Best for APIs that serve both browser and programmatic clients.HeaderOnlyExtractor
Reads only from the
Authorization header. Use this when cookies are never expected (e.g., pure REST APIs consumed by mobile apps).CookieOnlyExtractor
Reads only from the
token cookie. Useful for traditional web apps where tokens are set server-side and cookies are the sole transport.Error Types
The middleware uses three sentinel errors. Your customErrorHandler can use errors.Is to distinguish them:
| Error | Default Status | Cause |
|---|---|---|
ErrNoToken | 401 | No token found in header or cookie |
ErrInvalidToken | 401 | Token signature invalid or expired |
ErrInvalidClaims | 403 | UserID is nil or Role is empty |
Accessing Token Data in Handlers
After the middleware runs, use these typed helpers to read values from the Gin context:Returns the authenticated user’s UUID and
true, or a zero-value UUID and false if the middleware did not run or was skipped.Returns the user’s role string from the JWT claims.
Returns the full
*jwt.Claims struct, giving access to UserID, Role, Extra, ExpiresAt, and any other fields defined in GoKit’s JWT package.Context Keys
GoKit stores auth data under typedcontextKey string constants. The helper functions (GetUserID, GetUserRole, GetClaims) are the recommended way to read these values in production code because they perform a safe type assertion. In tests you may need to seed the context directly using the raw string values:
| Constant | Raw string value | Holds |
|---|---|---|
ctxUserIDKey | "gokit:user_id" | uuid.UUID |
ctxRoleKey | "gokit:user_role" | string |
ctxClaimsKey | "gokit:claims" | *jwt.Claims |
The constants
ctxUserIDKey, ctxRoleKey, and ctxClaimsKey are unexported. Use the string literals shown above when seeding a *gin.Context in unit tests.Role-Based Access Control
RequireRole is a secondary middleware that must be placed after Auth. It reads the role that Auth injected into the context and aborts with 403 if the role is not in the allowed list. Denied attempts are logged at SecurityLevel.
If
GetUserRole returns false (Auth was not run or was skipped), RequireRole responds with 401 rather than 403. Always chain it after Auth.