H2CK
Question: Why are there backslashes in front of forward slashes?
it appears that the configuration at .well-known/openid-configuration has backslashes in front of every forward slash. I have never something like that and wondered what the reasons is?
I have never seen such a problem before with the wellknown endpoint. I verified at my own live installation: Here everything is fine. Could you provide an example of the output of the endpoint?
Here is my openid config with redacted domain names:
{"issuer":"https:\/\/nextcloud.mydomain.app","authorization_endpoint":"https:\/\/nextcloud.mydomain.app\/apps\/oidc\/authorize","token_endpoint":"https:\/\/nextcloud.mydomain.app\/apps\/oidc\/token","userinfo_endpoint":"https:\/\/nextcloud.mydomain.app\/apps\/oidc\/userinfo","jwks_uri":"https:\/\/nextcloud.mydomain.app\/apps\/oidc\/jwks","scopes_supported":["openid","profile","email","roles","groups"],"response_types_supported":["code","code id_token","id_token"],"response_modes_supported":["query"],"grant_types_supported":["authorization_code","implicit"],"acr_values_supported":["0"],"subject_types_supported":["public"],"id_token_signing_alg_values_supported":["RS256","HS256"],"userinfo_signing_alg_values_supported":["none"],"token_endpoint_auth_methods_supported":["client_secret_post"],"display_values_supported":["page"],"claim_types_supported":["normal"],"claims_supported":["iss","sub","aud","exp","auth_time","iat","acr","azp","preferred_username","scope","nbf","jti","roles","name","updated_at","website","email","email_verified","phone_number","address","picture"],"end_session_endpoint":"https:\/\/nextcloud.mydomain.app\/apps\/oidc\/logout"}
There is nothing special the oidc app is doing here. It just generates a JSON response (without the backslashes) and the Nextcloud core is performing a json_encode on the JSONResponse passed from the oidc app. Depending on your PHP / server environment settings it seems that the flag JSON_UNESCAPED_SLASHES is used by the Nextcloud core to perform the encoding.
Btw: The notation with backslashes is anyhow a valid JSON representation.
Ok, thanks for your reply.
I will follow up when i tested it after changing the flag.
In my scenario i am using an envoy proxy with a WASM-plugin inside that handles OIDC (see my repo). For some reason it cannot handle backslashes out of the box but i will look into it.
Much appreciated. Cheers !