Hi @Salesforce Identity I'm attempting an integration from SF to a 3rd party using @Chuck Liddellgenius work around for Named Credentials using Client Credentials. I found some additional expert guidance through SF Stack Exchange (link below) to adapt it to use a post request for the token endpoint, which is what my 3rd party requires. I've been able to get the Named Credential to authenticate, which gives me the token as expected.
While the token is active, I can make an HTTP callout from Apex referencing the Named Credential name in setting the endpoint in the HTTP request like this: req.setEndpoint(callout:My_Named_Credential/some_path'). It works fine, and gets the expected response. However, after the token expires, I'm trying to run that same HTTP callout to get a refresh token (because it will return 401), but my apex code does not recognize my Named Credential reference in my HTTP Request. As soon as the callout request is made, I get 'java.lang.IlliegalArgumentException: invalid start or end'. This refresh process actually worked one time a couple days ago but hasn't worked since. Has anyone else had this problem with Named Credentials? I can't find any references online about this same issue. I would really appreciate any assistance, please. Thank you!
I promised an update. The Salesforce product team has been looking into this issue for several weeks now, and I just received the findings:
From SF product support:
The third-party endpoint is sending wrong WWW-Authenticate header values.
From debugging, they could see the following WWW-Authenticate headers.
---
www-authenticate: Bearer realm="Service"
www-authenticate: error="invalid_token"
www-authenticate: error_description="The access token provided has expired"
---
* You can see this fact by using curl.
** curl -v -H "Authorization: Bearer e4985b7611eb62a5b51aee9f54aaa9e907e23ddb" (to 3rd party endpoint which I removed here)
The first one above is valid. However the second and the third ones are violated to RFC.
Please refer to
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/WWW-Authenticate.
Unfortunately, Java(that our platform is based on)'s Http feature can't parse such wrong header value, as the result, the java.lang.IllegalArgumentException happens internally.
_________
I have passed along this info to the 3rd party. I want to give a huge shout out to SF Support (Abhinav Korada, Dev Support rep on my ticket) and the Product Team for getting to the bottom of this issue. I really appreciate all the time and effort. Thank you so much!
@Courtney Dascenzo @Samuel Rosen @David Brossard
