Reply
Highlighted
Regular Contributor
Posts: 61
Registered: ‎02-24-2017
Accepted Solution

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?


Accepted Solutions
Solution
Accepted by topic author jima
‎09-18-2017 01:44 PM
Posts: 423
Topics: 0
Kudos: 88
Blog Posts: 0
Ideas: 0
Solutions: 34
Registered: ‎04-28-2017

Re: Accept.js authentication/security

[ Edited ]

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


All Replies
Posts: 423
Topics: 0
Kudos: 88
Blog Posts: 0
Ideas: 0
Solutions: 34
Registered: ‎04-28-2017

Re: Accept.js authentication/security

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
Regular Contributor
Posts: 61
Registered: ‎02-24-2017

Re: Accept.js authentication/security

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?

Solution
Accepted by topic author jima
‎09-18-2017 01:44 PM
Posts: 423
Topics: 0
Kudos: 88
Blog Posts: 0
Ideas: 0
Solutions: 34
Registered: ‎04-28-2017

Re: Accept.js authentication/security

[ Edited ]

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
Regular Contributor
Posts: 61
Registered: ‎02-24-2017

Re: Accept.js authentication/security

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

Posts: 423
Topics: 0
Kudos: 88
Blog Posts: 0
Ideas: 0
Solutions: 34
Registered: ‎04-28-2017

Re: Accept.js authentication/security

[ Edited ]
That's correct.
Powered by NexWebSites.com -
Certified Authorize.net developers