topic Re: SECURING API in cybersource APIs

SECURING API

jhonI99 — Wed, 20 Apr 2022 15:35:31 GMT

Hy every one how I am secure my API from multiple request and interaction during work and keep my secrecy.

Re: SECURING API

JamesZimmerman — Tue, 03 May 2022 06:02:25 GMT

You could use a JWT (Json web token) that is generated by your UI implementations when they make API requests. JWTs require a secret code to sign them only known to the UI and the API. The UI creates a token and send it to the API which will then verify it is an authenticated request. The token has an expiration to prevent a third party, scraper, from "recording" the action and replaying them later.
To handle the credentials I believe sites like Facebook also use oauth tokens that are created after you register your application but I am not certain. If you are getting credentials in plain text on your site and transmitting them you should be using https in any case.

Hope that helps

Re: SECURING API

RickyReyesmatri — Thu, 05 May 2022 05:08:15 GMT

No you can't really secure an API endpoint to only allow specific callers without locking it down so it isn't public (e.g. by IP), or you can secure the client (trusted client infrastructure). Since you can't do that with a mobile app, etc., no you are screwed.

However, that means you have to look into other options, like instead of securing the client, secure the USER. Then it's up to the user to trust the client they are using with their password.

Or, once you realize that the server side is the only thing that can be protected, you go full OAuth, and require the app to redirect to your trusted servers for authentication (e.g., user creds never go through app), and the user "grants" the app the ability to act in your stead with a ticket that is a stand in for an authenticated "session" (A lot like a power of attorney actually).

OAuth inherently wants you to use very short lived tickets (a few minutes), and refresh tokens to establish a longer lived session that refreshes the real ticket after an expiration without having to task the user with logging in again to get a new one.

And yes, you can steal those. It's essentially like cookie / session hijacking, and for the same reasons that sessions should be short lived, an auth token should be short lived.