We have a requirement to call web API which uses Bearer Token authentication type and it requires client id and secret in the Header.
Before calling this API we need to get the access token using oAuth endpoint, this endpoint has authentication type as Basic Auth and it requires same client id and secret in the Header.
1. For OAuth endpoint, we have created a connected system (A) with the Basic Authentication using username and password. - Works fine.
2. For the primary API, we have created another connected system (B) with the following information.
a. Base URL: <Base URL>.
b. Authentication: None
3. Created an Integration object which uses connected system B and has following parameters in the Headers.
a. Authorization: <Token received in step #1, passed as rule input>
b. X-IBM-Client-Id: <client id, passed as constant >
c. X-IBM-Client-Secret: <client secret, passed as constant>
The above setup works fine however as per our security compliance we cannot have a secret in the constant which is non-masked.
Is there a way for us to use connected system which supports the masked password and secret to achieve above scenario?
Discussion posts and replies are publicly visible
Abhay Dalsaniya said:Is there a way for us to use connected system which supports the masked password and secret to achieve above scenario?
Have you looked into whether it's possible to make this work along with the Credential Store? I don't happen to know but I'd be surprised if there isn't some way.
Why not add that client secret in the connected system instead of leaving authentication to "None"?
I hope you have already considered 'OAUTH 2.0: SAML BEARER ASSERTION FLOW' where client secret is masked.
https://docs.appian.com/suite/help/24.1/oauth_saml_bearer_assertion_flow.html
We can but is there a way to refer the id and secret from CS to pass in the Header?
This does not work for us. If we provide the id and secret in the Header, it will still be in plain text and will be visible.
I did not find a way to use Credential Store fields directly in the CS or Integration object.
The API supports the Bearer auth type and need to pass id and secret in the header. Header will be always a plan text and will be visible. Also in above we cannot pass the user and password for oAuth EP, and hence cannot retrieve the auth token.
Dang, that's disappointing. Maybe (in the meantime) open a product use case with Appian? It seems like there should be a way to do this. (cc Peter Lewis )
Abhay Dalsaniya said:If we provide the id and secret in the Header
Isn't the header passed over as plaintext anyway - the way you phrase it (and pardon me being slightly less familiar with this auth method) but it sounds as if your setup itself is what's violating your security requirements (i.e. the secret is being passed as header, which is plaintext, which is not allowed - this would still be true whether you figure out a way to mask the value in the configuration dialog, no? Or do I have something confused here?)