Hi,
We have user report that changing the Token endpoint authentication method from Client secret with symmetrically signed JWT assertion seems to behave the same as Client secret over HTTP POST authentication. Thus, please verify if the current MitreID behavior have a default to just accepting the Client_ID and Client_Secret if it sees it in the content of the link.
e.g. a jtest token endpoint authentication set to Client secret with symmetrically signed JWT assertion but with the valid client_id and client_secret (especially a client created by user) in HTTP header or HTTP body to check if it can validate.
In addition to that, users have reported that changing a client with existing client secret to no authentication needs the existing client secret, while a brand new client that never have any client secret set can be authenticated with No auth as it is still ""
Hi,
We have user report that changing the Token endpoint authentication method from
Client secret with symmetrically signed JWT assertionseems to behave the same asClient secret over HTTP POST authentication. Thus, please verify if the current MitreID behavior have a default to just accepting the Client_ID and Client_Secret if it sees it in the content of the link.e.g. a jtest token endpoint authentication set to
Client secret with symmetrically signed JWT assertionbut with the valid client_id and client_secret (especially a client created by user) in HTTP header or HTTP body to check if it can validate.In addition to that, users have reported that changing a client with existing client secret to no authentication needs the existing client secret, while a brand new client that never have any client secret set can be authenticated with No auth as it is still
""