Verify a Clerk session in Go
There are two ways to verify a session with Clerk in your Go application:
-
Using Clerk middleware
If you want to verify a session in an HTTP context, it is recommended to use Clerk middleware. Clerk middleware guarantees better performance and efficiency by making the minimum necessary requests to the Clerk Backend API. -
Manually verifying the session token
If you want to verify a session in a non-HTTP context, or if you would like total control over the verification process, you can verify the session token on your own.
Use Clerk middleware to verify a session
Go enables you to create a simple HTTP server, and Clerk enables you to authenticate any request. Together, you can create a secure server that only allows authenticated users to access certain routes.
Clerk Go SDK provides two functions for adding authentication to HTTP handlers:
WithHeaderAuthorization()
RequireHeaderAuthorization()
, which callsWithHeaderAuthorization()
under the hood, but responds withHTTP 403 Forbidden
if it fails to detect valid session claims.
Both middleware functions support header based authentication with a bearer token. The token will be parsed, verified, and its claims will be extracted as SessionClaims
.
The claims will then be made available in the http.Request.Context
for the next handler in the chain. Clerk Go SDK provides the SessionClaimsFromContext()
helper for accessing the claims from the context.
The following example demonstrates how to use the WithHeaderAuthorization()
middleware to protect a route. If the user tries accessing the route and their session token is valid, the user's ID and banned status will be returned in the response.
Manually verify a session token
Verifying a Clerk session manually is useful when you want to verify a session in a non-HTTP context, or if you would like total control over the verification process. With the solution above, Clerk middleware makes the minimum necessary requests to the Clerk Backend API. With this solution, you must be mindful of API rate limits.
Verifying a session token requires providing a JSON Web Key. When using Clerk middleware to verify a session, it fetches the JSON Web Key once and caches it for you. However, when manually verifying a session, there's no caching layer for the JSON Web Key.
Clerk Go SDK provides a set of functions for decoding and verifying JWTs, as well as fetching JSON Web Keys. It is recommended to cache your JSON Web Key and invalidate the cache only when a replacement key is generated.
The following example demonstrates how to manually verify a session token. If the user tries accessing the route and their session token is valid, the user's ID and banned status will be returned in the response.
If you need to verify session tokens frequently, it's recommended to cache the JSON Web Key for your instance in order to avoid making too many requests to the Clerk Backend API.
The following example includes the same code as above, with the addition of demonstrating a possible way to store your JSON Web Key. The example is meant to serve as a guide; implementation may vary depending on your needs.
Feedback
Last updated on