Suggestions wished: Orionis, service-to-service OAuth2 shopper credentials for Go/Gin – Neighborhood

Hello,

I launched Orionis v0.2.0 and would respect suggestions from Go builders on the API form, safety mannequin, and docs:

Orionis is a compact Go toolkit and Gin authorization server for service-to-service OAuth2 client_credentials. It points signed JWT entry tokens, exposes JWKS, caches shopper tokens, and contains Gin middleware for useful resource providers.

It’s deliberately scoped to machine-to-machine auth, not end-user login or a full identity-provider suite.

The README features a three-process native demo:

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

The demo shopper ought to get standing=201 from the protected billing service.

I’m particularly focused on suggestions on:

• Whether or not the chain-first builders are idiomatic sufficient for Go providers.
• Whether or not the JWKS/token validation conduct is evident from the docs.
• Any safety or deployment issues earlier than this will get extra utilization.

Thanks.

Thanks, good level ))

I added a brief JWKS validation lifecycle part to the README close to the Gin resource-service instance

I hope it clarifies that requests with contemporary cached keys are validated fully in reminiscence, with no per-request name to the authorization server

I’m curious, how does Orionis deal with JWKS key rotation and token validation when the cached keys expire? Does it mechanically refresh them, or does the service have to deal with that manually?

Orionis refreshes distant JWKS mechanically. Your service doesn’t want a guide refresh loop

You’ll be able to tune RefreshEvery(…) and MaxStale(…), or explicitly name provdier.Refresh(ctx) to preload or power a refresh