Domino core rejects OAuth bearer tokens whose scp claim is a JSON array. The token is otherwise valid: correct issuer, correct audience, valid signature, and the signing key loads successfully from the provider's JWKS. The Domino REST API management console reports the identity provider as OK with the correct KID.
The server log shows:
Type violation error parsing introspection data. Claim: scp, expected: string, actual: array Could not parse JWT token: Invalid ASN.1 syntax
The request then fails with HTTP 401.
This makes Okta unusable with Domino bearer authentication and with the oidc-idpcat provider in the Domino REST API. Okta builds the scp claim from the granted scopes and always writes it as a JSON array. There is no setting to change the type, and a custom claim named scope is not emitted in the token, so this cannot be worked around on the Okta side.
It is worth noting that scp is not defined in any RFC. RFC 6750 and RFC 9068 do not mention it. RFC 9068 defines a scope claim and refers to RFC 8693 section 4.2, which specifies scope as "a JSON string containing a space-separated list of scopes". The string requirement therefore applies to scope, not to scp. scp is a vendor convention and vendors differ. Microsoft Entra ID documents scp as "String, a space separated list of scopes", while Okta emits an array. This is why Entra ID works with Domino and Okta does not.
There is also an inconsistency inside the product. The Domino REST API's own JWT validator accepts the same token with scp as an array and resolves the user correctly, returning HTTP 200 from /api/v1/userinfo. Domino core rejects it. The same token produces two different results depending on which component validates it.
Requested change: when parsing scp, accept either a JSON string or a JSON array of strings, treating the array as the equivalent scope list. Providers that already send a string would be unaffected.
Impact: Okta is one of the most widely deployed identity providers. Any customer using Okta with Domino bearer authentication or oidc-idpcat will hit this and cannot resolve it through configuration. HCL support has confirmed the cause and advised raising this here. oidc-idpcat has been described to me as the preferred direction for 14.5, which makes the gap more significant rather than less.
Environment: Domino 14.5.1, Domino REST API 1.1.7, Windows Server. Identity provider: Okta custom authorization server.
