Some services I am working with require a REST Post to an authorization endpoint obtain a session token to be used in the header in subsequent REST calls. The authorization endpoint requires the account credentials to be passed in a JSON object in the request body.
This can be accomplished easily enough in SnapLogic by using a JSON Generator and a REST Post Snap.
However, this is not ideal from a security or account management perspective because the account credentials are stored directly in the pipeline in plain text and not as an account object.
Is there a better way to store credentials and use them in a pipeline for services that use this kind of authentication pattern?
1 ACCEPTED SOLUTION
@jervin @Spiro_Taleski @kamalaker.pinna Actually this is possible but this is somewhat of an undocumented feature that does not have finished integration with our UI - however I will describe how this can be done with the REST Snap Packโs Basic Auth and OAuth accounts.
The REST Snaps (POST/GET etc) are able to reference the account configured on the Snap through a special account variable, account.
This is different that how standard variables are referenced; per-document variables that come from an input document have the "$" prefix (e.g. $someField, whose value can be different for each input document to the Snap) and pipeline variables, called Pipeline Parameters, that are static for the pipeline execution lifecycle and denoted with the underscore prefix (e.g. _someParameter).
However, if a field is expression-enabled and uses a value of account in the REST Snap Pack, a reference to the account (if compatible) can make some fields from that account accessible to the Snap configuration.
Unfortunately our UI integration here is incomplete here for Basic Auth and it will generate a UI error, but the account data binding will actually work correctly.
So for a Basic Auth account, you could do the following:
The account.username and account.password account variables will bound to their respective values and then sent as part of the HTTP request body.
For OAuth 2.0 accounts, the only account variable field available is account.access_token (which is mentioned on the documentation) - this gives access to the OAuth access token.
It may be possible to use this technique to simplify and secure your solution, but it does have some downsides in terms of our product interface experience plus the complications that can arise when the Snap attempts to use the account credentials in the way it expects in addition to the customizations made to the request by the user.
Perhaps you can try this out and let me know your feedback please.
