feat(oauth): support generic OIDC/OAuth providers and fix misleading errors (closes #1247)

[emanuelbesliu]

Name of feature:

Generic OIDC/OAuth provider support for step oauth (closes #1247)

Pain or issue this feature alleviates:

step oauth --provider was awkward to use with a self-hosted or local identity provider such as Keycloak:

• A plaintext http:// provider (a common local test setup) was rejected outright — the exact scenario reported in Support non-tls providers for the oauth command http:// #1247.
• The validation error claimed only google or github were valid, even though an https:// issuer URL already worked, so the message was misleading:

  $ step oauth --client-id=test-client-000 \
      --provider=http://localhost:8080/realms/test/.well-known/openid-configuration
  use a valid provider: google or github
  

• Endpoint discovery only ever tried the OpenID Connect /.well-known/openid-configuration path (a long-standing in-code TODO), so OAuth 2.0 authorization servers that only publish RFC 8414 metadata could not be discovered.
• A non-OIDC response (404 / HTML) produced a confusing unsupported format error instead of reporting the HTTP status.

Why is this important to the project (if not answered above):

It makes step oauth usable with any standards-compliant OIDC/OAuth provider (Keycloak, Authentik, Dex, etc.) — including local test instances — without requiring users to hand-supply --authorization-endpoint / --token-endpoint. This is a frequent homelab/self-hosted CA workflow (Keycloak as the OIDC provisioner for step-ca).

Is there documentation on how to use this feature? If so, where?

The --provider usage text in step oauth --help is updated to describe OIDC + RFC 8414 discovery and the --insecure requirement for plaintext http:// providers.

In what environments or workflows is this feature supported?

• https:// issuer URLs (unchanged default behavior).
• http:// issuer URLs only with --insecure (matching the existing implicit-flow gating) — intended for local test IdPs.
• Providers exposing OIDC discovery, RFC 8414 OAuth metadata, or a direct /.well-known/... URL.

In what environments or workflows is this feature explicitly NOT supported (if any)?

Plaintext http:// providers without --insecure are still rejected, so the default behavior remains TLS-only.

Supporting links/other PRs/issues:

• Closes Support non-tls providers for the oauth command http:// #1247
• RFC 8414 §5: https://datatracker.ietf.org/doc/html/rfc8414#section-5

---

Implementation notes

• Validate(): accept OIDC/OAuth issuer URLs; clearer error message.
• oauthCmd: gate plaintext http:// behind --insecure via errs.RequiredInsecureFlag.
• disco(): try OIDC discovery, then fall back to RFC 8414 OAuth metadata; honor a URL already pointing at a /.well-known/ document.
• fetchDiscovery(): surface non-200 status codes.
• Adds command/oauth/cmd_test.go (the package previously had no tests) covering Validate() and all disco() paths.

Tested with go test ./command/oauth/; gofmt and go vet clean.

[CLAassistant]

All committers have signed the CLA.