Feedback wanted: Orionis, service-to-service OAuth2 client credentials for Go/Gin

Community
1

Hi,

I released Orionis v0.2.0 and would appreciate feedback from Go developers on the API shape, security model, and docs:

Orionis is a compact Go toolkit and Gin authorization server for service-to-service OAuth2 client_credentials. It issues signed JWT access tokens, exposes JWKS, caches client tokens, and includes Gin middleware for resource services.

It is intentionally scoped to machine-to-machine auth, not end-user login or a full identity-provider suite.

The README includes a three-process local demo:

  1. go run ./cmd/orionis-auth -config ./config/orionis.example.json
  2. go run ./examples/gin-billing-service
  3. go run ./examples/gin-orders-client

The demo client should get status=201 from the protected billing service.

I am especially interested in feedback on:

  • Whether the chain-first builders are idiomatic enough for Go services.
  • Whether the JWKS/token validation behavior is clear from the docs.
  • Any security or deployment concerns before this gets more usage.

Thanks.

3

Thanks, good point ))

I added a short JWKS validation lifecycle section to the README near the Gin resource-service example

I hope it clarifies that requests with fresh cached keys are validated entirely in memory, without a per-request call to the authorization server

4

I’m curious, how does Orionis handle JWKS key rotation and token validation when the cached keys expire? Does it automatically refresh them, or does the service need to handle that manually? :thinking:

5

Orionis refreshes remote JWKS automatically. Your service doesn’t need a manual refresh loop

You can tune RefreshEvery(…) and MaxStale(…), or explicitly call provdier.Refresh(ctx) to preload or force a refresh