cancel
Showing results forย 
Search instead forย 
Did you mean:ย 

Accept.js authentication/security

When making a client (JavaScript) call, a form of authentication is expected by Accept.js. If requires an apiLoginID and a clientKey. So my question is:

What is considered acceptable practice for the storage/display/use of those 2 elements? Not sure if I've worded that clearly though. I'm wondering whether it is considered acceptable/normal, if someone were to "view-source" of the JavaScript that makes the call to Accept.js, that the apiLoginID and clientKey would be viewable in the JS source? If not, what is an example of ways to collect and use them from within the calling function?

jima
Regular Contributor
1 ACCEPTED SOLUTION

Accepted Solutions

Because the ClientKey combined with an APILogin only allows you to retrieve a token with encrypted payment data. You still need to use your private TransactionKey, in order to do anything with the token.

 

The Authorize.Net Client Key is used in place of the traditional Transaction Key. The Client Key is a public key suitable for use where someone other than merchant might see it.

Powered by NexWebSites.com -
Certified Authorize.net developers

View solution in original post

NexusSoftware
Trusted Contributor
6 REPLIES 6
The clientKey was designed to be used as a public key as opposed to your Transaction Key which should be private.
Powered by NexWebSites.com -
Certified Authorize.net developers
NexusSoftware
Trusted Contributor

Yes, that is understood. But still, the question remains.

 

Why is it secure to have the user (apiLoginID) and the (public) clientKey exposed? Is there domain validation performed, or some other such validation? Or, is it not advisable to have both exposed (via "view source" or similar), as initially asked?

jima
Regular Contributor

Because the ClientKey combined with an APILogin only allows you to retrieve a token with encrypted payment data. You still need to use your private TransactionKey, in order to do anything with the token.

 

The Authorize.Net Client Key is used in place of the traditional Transaction Key. The Client Key is a public key suitable for use where someone other than merchant might see it.

Powered by NexWebSites.com -
Certified Authorize.net developers
NexusSoftware
Trusted Contributor

Oh, ok... So the idea here is that the public clientKey and apiLoginID combination is ONLY good for attaining a Nonce, nothing more? If that's the case, then it makes sense that their both being exposed is not a risk.

Am I now understanding it right? If so, thanks! :D

jima
Regular Contributor
That's correct.
Powered by NexWebSites.com -
Certified Authorize.net developers
NexusSoftware
Trusted Contributor

Yes, that is understood. But still, the question remains.

 

Why is it secure to have the user (apiLoginID) and the (public) clientKey exposed? https://www.wizlynxgroup.com/ch/en/ Is there domain validation performed, or some other such validation? Or, is it not advisable to have both exposed (via "view source" or similar), as initially asked?

sxcscooters
Member