API keys and bearer tokens have different jobs

What the public implementation shows

SIPS Connect includes API-key authentication handlers and providers alongside bearer-token auth services, roles, and operation filters.

Credential validation is separated from controller operation authorization and from the financial handler being invoked. This is the implementation fact behind the note; the architectural reading begins from that visible boundary rather than from an assumed production story.

Operating principleAuthentication mechanisms can coexist only when identity and permission remain explicit.

The decision behind the mechanism

Dual support enables participant migration while keeping a common authorization and audit boundary above the credential type.

If an API key implicitly means administrator, a legacy credential can bypass the role and operation controls applied to bearer tokens. The mechanism matters because it gives that failure a named boundary, durable evidence, and a controlled response instead of leaving the outcome to timing or operator guesswork.

• Hash stored API keys and compare safely.
• Map every key to an explicit principal and scope.
• Apply the same endpoint policy after authentication.
• Measure fallback usage so it can be retired.

How the control should be operated

Every credential should map to a named client or principal, permitted operations, rotation owner, expiry policy, and observable use.

The platform can transition mechanisms without creating an untraceable fallback identity. The reusable lesson is not to copy a class or endpoint in isolation, but to preserve the relationship between identity, state, authority, evidence, and operational ownership.