authorization_endpoint and login provider

[safehome-jdev]

Instructions and app callback error page imply that the URL to login with the IdP provider should be the authorization_endpoint and not issuer. Testing with Azure AD and utilizing the authorization_endpoint (v1 or v2) from the Endpoints field within an App registration does not provide a valid login location for this auth flow.

Pulling the .well-known/openid-configuration for my Azure instance shows the following endpoints/config for Azure:

{
  "token_endpoint": "https://login.microsoftonline.com/[TENANT_ID]/oauth2/v2.0/token",
  "token_endpoint_auth_methods_supported":
    ["client_secret_post", "private_key_jwt", "client_secret_basic"],
  "jwks_uri": "https://login.microsoftonline.com/[TENANT_ID]/discovery/v2.0/keys",
  "response_modes_supported": ["query", "fragment", "form_post"],
  "subject_types_supported": ["pairwise"],
  "id_token_signing_alg_values_supported": ["RS256"],
  "response_types_supported":
    ["code", "id_token", "code id_token", "id_token token"],
  "scopes_supported": ["openid", "profile", "email", "offline_access"],
  "issuer": "https://login.microsoftonline.com/[TENANT_ID]/v2.0",
  "request_uri_parameter_supported": false,
  "userinfo_endpoint": "https://graph.microsoft.com/oidc/userinfo",
  "authorization_endpoint": "https://login.microsoftonline.com/[TENANT_ID]/oauth2/v2.0/authorize",
  "device_authorization_endpoint": "https://login.microsoftonline.com/[TENANT_ID]/oauth2/v2.0/devicecode",
  "http_logout_supported": true,
  "frontchannel_logout_supported": true,
  "end_session_endpoint": "https://login.microsoftonline.com/[TENANT_ID]/oauth2/v2.0/logout",
  "claims_supported":
    [
      "sub",
      "iss",
      "cloud_instance_name",
      "cloud_instance_host_name",
      "cloud_graph_host_name",
      "msgraph_host",
      "aud",
      "exp",
      "iat",
      "auth_time",
      "acr",
      "nonce",
      "preferred_username",
      "name",
      "tid",
      "ver",
      "at_hash",
      "c_hash",
      "email",
    ],
  "kerberos_endpoint": "https://login.microsoftonline.com/[TENANT_ID]/kerberos",
  "tenant_region_scope": "NA",
  "cloud_instance_name": "microsoftonline.com",
  "cloud_graph_host_name": "graph.windows.net",
  "msgraph_host": "graph.microsoft.com",
  "rbac_url": "https://pas.windows.net",
}

Instructions show:

    // URL of provider. All other URLs are auto-discovered from .well-known
    'oidc_login_provider_url' => 'https://openid.example.com',

My initial configuration

    // URL of provider. All other URLs are auto-discovered from .well-known
    'oidc_login_provider_url' => 'https://login.microsoftonline.com/[TENANT_ID]/oauth2/v2.0/authorize',

Callback error (once I fixed the issue, the well-known url stuck. Sorry, I couldn't get a screenshot):

The provider authorization_endpoint could not be fetched. Make sure your provider has a well known configuration available.

I double and triple checked that the authorization_endpoint was what Azure stated. I swapped my authorization_endpoint for my /.well-known/openid-configuration since it seemed that the code was looking for the well known config after all. I found that line 654 was trimming whitespace, but not taking into account URLs that already contained the path /.well-known/openid-configuration.

Once I used the root URL for my issuer (https://login.microsoftonline.com/[TENANT_ID]/v2.0), I was able to be redirected to Azure's login page. It looks like line 654 is concatenating any URL to add /.well-known/openid-configuration even if it is already present.

The $well_known_config_url variable should probably either:

1. recognize that the path exists
2. clearly show the URL it's attempting on the callback error page so an admin knows what's wrong
3. or not attempt to concat the path at all and ensure the admin is using the .well-known/openid-configuration path to begin with

This is one of my first issue(s) I have ever reported, please be gentle.

[pulsejet]

The $well_known_config_url variable should probably either:

1. recognize that the path exists

This is good.

2. clearly show the URL it's attempting on the callback error page so an admin knows what's wrong

This is even better. Definitely should do this one.

3. or not attempt to concat the path at all and ensure the admin is using the .well-known/openid-configuration path to begin with

This we can't do cause it breaks backward compatibility.

This is one of my first issue(s) I have ever reported, please be gentle.

Keep going; many more to come!