• AuthDeck

Real Providers Push Back

As soon as AuthDeck met a real provider, it learned something. The Logto Management API doesn’t just want an access token—it wants one scoped to a specific resource. Without it, the token is issued but rejected at the door.

That’s a gap a hand-written config can’t paper over. So the provider definition grew a field.

The resource Parameter

Some OAuth servers (Logto among them) expect a resource parameter alongside the usual client credentials. It tells the authorization server which API the token is meant for. AuthDeck now carries it through every flow:

• Client Credentials — sent in the token request.
• Refresh Token — sent when renewing.
• Authorization Code — sent both in the authorization URL and the token exchange.

The configuration stays declarative:

providers:
  logto-m2m:
    client_id: "${LOGTO_M2M_CLIENT_ID}"
    client_secret: "${LOGTO_M2M_SECRET}"
    token_url: "https://example.logto.app/oidc/token"
    scopes: ["all"]
    resource: "https://example.logto.app/api"
    flow: "client_credentials"

Order Matters

The second lesson was subtler. Go maps have no defined iteration order, so the provider list in the TUI shuffled on every run. That’s disorienting when you rely on muscle memory—[1] should always be the same provider.

The fix was to read the provider names separately, in declaration order, by walking the raw YAML node tree. The runtime still uses a map for lookups, but the display order comes straight from the file. What you write is what you see.

Real usage is the only honest test of a config format. The resource field and stable ordering weren’t in the original plan—they emerged the moment AuthDeck had to work with something other than a toy provider. That’s the normal shape of building tools: the edges push back, and you widen the tool just enough.