Defaults, Not Fallbacks

Real providers rarely follow the spec to the letter. The latest nudge came from an internal IdP that returns the token under a field that isn’t access_token. Same protocol, different shape. If AuthDeck only ever reads one field name, it can’t talk to half the identity providers in the wild.

So the response shape became configurable:

providers:
  internal:
    token_url: "https://idp.internal/oauth/token"
    token_path: "data.token" # default: access_token
    token_type_path: "token_type" # default: token_type
    expires_path: "expires_in" # default: expires_in

Dotted Paths, Not a Query Language

The value is a dotted path—data.token—not a full JSONPath expression. That’s a deliberate limit. Dotted paths cover nested objects, which is what real responses actually need. Pulling in a query language for array filters and recursive descent would be a lot of machinery for cases that don’t exist here.

Enough, not everything.

Why There’s No Fallback

The tempting move is a safety net: if data.token isn’t found, quietly try access_token. It sounds forgiving. It isn’t. A silent fallback turns a configuration mistake into a mystery—one provider returns a token, another doesn’t, and nothing tells you why.

So there is none. Defaults apply when you say nothing. The moment you name a path, that path is the contract. If it isn’t there, AuthDeck stops with a precise error: access token not found at path “data.token”. Failures should point at the cause, not hide it.

Defaults and fallbacks look similar and behave nothing alike. A default is a decision you didn’t have to make; a fallback is a guess made on your behalf. One reduces friction. The other hides the truth.