authorization_endpoint missing from OIDC .well-known configurations (Identity Tokens Backend)

[gugalnikov]

Describe the bug
The documentation (https://www.vaultproject.io/api/secret/identity/tokens.html) states that .well-known configuration should look like:

{
  "issuer": "https://example.com:1234",
  "authorization_endpoint": "",
  "token_endpoint": "",
  "jwks_uri": "https://example.com:1234/.well-known/keys",
  "response_types_supported": null,
  "subject_types_supported": [
    "public"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256"
  ],
  "scopes_supported": null,
  "token_endpoint_auth_methods_supported": null,
  "claims_supported": null
}

but I'm actually getting:

{
  "issuer": "http://127.0.0.1:8200/v1/identity/oidc",
  "jwks_uri": "http://127.0.0.1:8200/v1/identity/oidc/.well-known/keys",
  "response_types_supported": [
    "id_token"
  ],
  "subject_types_supported": [
    "public"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256",
    "RS384",
    "RS512",
    "ES256",
    "ES384",
    "ES512",
    "EdDSA"
  ]
}

To Reproduce
Steps to reproduce the behavior:

1. Run: curl
   --request GET
   http://127.0.0.1:8200/v1/identity/oidc/.well-known/openid-configuration

Expected behavior
authorization_endpoint should be included in the response with a meaningful value for other parties which want to use Vault as OIDC provider and are reading this configuration

Environment:

• Vault Server Version (retrieve with vault status): 1.3.0
• Vault CLI Version (retrieve with vault version): 1.3.0
• Server Operating System/Architecture: Linux ubuntu1604-0741 4.4.0-169-generic

Vault server configuration file(s):

{
  "backend": {
    "file": {
      "path": "/vault/file"
    }
  },
  "listener": {
    "tcp":{
      "address": "0.0.0.0:8200",
      "tls_disable": 1
    }
  },
  "ui": true,
  "plugin_directory": "/vault/plugins",
  "api_addr": "http://127.0.0.1:8200"
}

Additional context
Add any other context about the problem here.

[tyrannosaurus-becks]

Hi @gugalnikov , can you provide further steps to reproduce? Which OIDC provider are you using (listed here)? Also, would the well-known response vary by provider?

[gugalnikov]

hi, just to clarify, this issue is related to the Identity Secrets Engine: https://www.vaultproject.io/docs/secrets/identity/index.html rather than to the OIDC Auth Method. The only necessary steps to reproduce this behavior would be to enable & configure the Identity Tokens Backend according to the official docs: https://www.vaultproject.io/api/secret/identity/tokens.html
I haven't tested this again with versions higher than 1.3..0, but I will soon

[kalafut]

Hi. The Identity Token support only produces ID Tokens for the requesting entity. It is not an IdP and doesn’t handle authorization nor issue access tokens.

There is some room for improvement here, however. The example and actual output don’t match, and we’ll need to check but it may be more correct to include those fields as empty strings in the output. A comment in the docs about why they’re not populated would be helpful too.

[gugalnikov]

That's helpful, thanks!!