Outbound Identity Federation OpenID Configuration seems to be not valid

What you are seeing is NOT a bug; it is a result of how AWS implements Outbound Identity Federation (specifically via IAM Roles Anywhere or IAM Identity Center).

The short answer is: AWS Outbound Identity Federation uses a "Headless" or "Token-Only" OIDC implementation. It is designed for programmatic exchange, not for the interactive browser-based flows (like Authorization Code Flow) that most OIDC Identity Providers support.

1. Why those fields are missing?

The RFC you cited (RFC 8414) and the OIDC Discovery specification define authorization_endpoint and response_types_supported as REQUIRED. However, those fields only make sense if the Identity Provider (IdP) supports a "front-channel" (a browser redirecting a user to a login page). AWS Outbound Federation is strictly a "back-channel" mechanism.

• No Authorization Endpoint: AWS does not host a login page where a user enters a username/password to get a code.
• No Token Endpoint: You don't "exchange" a code for a token at a public endpoint via a POST request in the traditional sense. Instead, AWS generates the token internally (via the STS service) and hands it to the caller or attaches it to the workload.

2. Is it a different protocol?

It is still technically OIDC/JWT, but it adheres to the "Self-Issued" or "Static" IdP pattern. In standard OIDC, the Flow is:

Client -> Authorization Endpoint -> Token Endpoint -> Token In AWS Outbound Federation, the flow is: AWS Service/Workload -> STS (generates JWT) -> Third-party Service

The third-party service provider (SP) is expected to be a "Resource Server" that validates the token locally using the jwks_uri. It does not need to "talk" to AWS to get the token; it only needs to "talk" to AWS to get the public keys to verify the signature.

3. Why your Service Provider is rejecting it?

Many commercial SaaS platforms (like GitHub, GitLab, or generic OIDC integrations) use OIDC libraries that strictly enforce the presence of the authorization_endpoint. If they don't see that field, they assume the Discovery document is malformed and abort.

4. How to fix/work around this:

If the service provider you are connecting to requires a "full" OIDC Discovery document, you have three options:

• Manual Configuration: If the Service Provider allows it, do not use the "Discovery URL." Instead, manually input the Issuer URL and the JWKS URL. Most libraries that allow manual entry only require the JWKS to validate the signature.
• The "Mock" Discovery Proxy: Some users host a small JSON file (e.g., in an S3 bucket or via a Lambda) that mirrors the AWS config but adds "dummy" values for the missing fields:

"authorization_endpoint": "https://example.com/unused",
"response_types_supported": ["id_token"],
"token_endpoint": "https://example.com/unused"

If the SP only uses the document to validate the issuer, this trick often works.

• Verify the Use Case: Outbound Federation is primarily meant for Workload Identity (e.g., an AWS Lambda calling a non-AWS API). If you are trying to set up User SSO (where a human logs into a dashboard), you should be using AWS IAM Identity Center (SAML/OIDC), which provides a full, standard-compliant discovery document.