FAQ

Is Wicket a standalone authentication service?

No. Wicket is a Go library that is embedded in your own HTTP service as func(http.Handler) http.Handler middleware. It provides no executable, admin console, or login UI — the login page, consent page, and user store are implemented by the host application, and Wicket handles the protocol itself. See What is Wicket for details.

Is it ready for production?

Wicket is at the 0.x stage: the public API may still change, and some protocol features are not fully in place yet (for example, the device authorization endpoint and the expiration and rotation policies for refresh tokens). The core paths — authorization code, client credentials, refresh tokens, discovery, introspection, and so on — are covered by integration and end-to-end tests. Before going live, go through the Production checklist item by item and pin a specific version.

Which Go version do I need?

Go 1.27 or later. go.mod declares go 1.27, so older toolchains can't resolve the module.

Do I have to use a database?

It depends on which capabilities you use:

• Only verifying external credentials (oidcverify / wechatverify / phoneverify): you need no storage at all, and no composition root either.
• Issuing tokens as an authorization server: you need persistent storage. The in-memory implementations are only suitable for local development — a process restart loses all authorization codes, refresh tokens, and sessions, and with multiple replicas requests also fail at random. See Persistence.

Which databases are supported?

There is an official PostgreSQL adapter, github.com/gonewx/wicket-pg. For other backends, you can implement your own by following Writing a storage adapter, and use Wicket's bundled conformance suites to verify that the behavior is consistent.

Is the resource owner password grant (password) supported?

Not by default; such requests are rejected. Current security best practices no longer recommend this grant. If a legacy system really needs it, you can enable it by injecting your own ResourceOwnerPasswordValidator through ServerConfig.

Why doesn't Wicket clean up expired data on a schedule itself?

A library shouldn't start background goroutines without the host knowing. Wicket exposes the cleanup entry points to the host so you can drive them with your own scheduling, timeouts, and logging policies. Expiration is always decided on the core side; cleanup only reclaims space and doesn't affect correctness.

The discovery document lists /connect/revocation — why does calling it have no effect?

In v0.1.4, the discovery document lists the URLs of endpoints such as revocation and device authorization, but no handlers are registered for these endpoints yet, so requests go straight to the host application. The Endpoint reference page is the authoritative list of registered endpoints.

How do I report a problem or contribute?

Open an issue or pull request on the GitHub repository. For security vulnerabilities, don't disclose details in a public issue; contact the maintainers privately first.