api - PHP - Securely sending request/response between 2 servers? -

summary: i've created app in php. it's lead management system call center. need allow partner able add new leads app integrating our app proprietary crm. in short, guess need build api app.

the easiest approach can think of simple html post. considered insecure? if so, best approach type of situation?

thanks help,

andrew.

through quest build api, you'll come across of these. i'm going outline concepts might come in handy build api usable, , follows open standards (which, in turn, makes trivial third-party adapt existing code interact it).

api dispositions

the first keyword is: ssl. don't ever think of not using it. provides secure socket layer on communication can happen in secure fashion, , consequently makes eavesdropping , mitm attacks more difficult conceive.

no matter what, not skip on this. certificates cost less $60/year, not costly, , can save lot in long run.

in terms of server techs, use want. main requirement webserver can handle 4 common http verbs: get, post, put, delete. i'll explain why in moment.

api authorisation

this 1 contentious field, lots of people "think have secure way so". answer not true. point of authentication allow client authenticate credentials, prevent third-party not privileged doing so.

simply adding api key feed lead getting hold of it. have seen specific thing many times advise against it, there easier options.

i'll go on couple of things, labelling them (a) or (s), respectively authentication , signature. signing method used render request tamper-proof. authentication proves are.

hmac-sha512 signing (a) (s)

this technique used amazon s3/aws apis, , lightweight method of signing , authenticating request. find relatively ingenious.

the basic idea:

1. round , post fields (including public key)
2. sort them alphabetically
3. concatenate them using urlencode or equivalent
4. perform hmac hashing cipher on data, private key key of hmac.
5. append result of 4 request.

this simple , ingenious. guarantees:

1. you cannot change request without knowing private and public keys
2. you cannot change key without changing request

this neatly wraps both issues using same http request @ cost of 1 reserved get/post field. amazon requires presence of timestamp in request, prevents replay attacks. neat!

(for reference: hmac-algo = algo( (key xor pad) concat algo(key xor pad2) concat message). algo can hash cipher - sha256 preferred lightweight nature)

oauth (a)

you've heard of it. idea simple: given key , secret. allows queue temporary token. token used perform requests.

the main advantage of lots of libraries exist handle it, both client-side , server-side. other advantage oauth has 2 modes of operation: two-legged (server->server without client interaction) , three-legged (client->server->server).

the main drawback 2 http requests token.

simply sending private keys through (a)

... leads replay attacks. don't consider it.

a mixture of methods possible things. hmac signage awesome when combined oauth, example!

api conception

api endpoints these days follow 2 main standards: soap (xml-rpc), or rest. if building endpoint post leads, may build corresponding api read leads , delete them future.

your api therefore take form:

 /my/endpoint/   - get: gets list of leads   - post: creates new lead  /my/endpoint/id/   - get: lead info   - put: modifies lead   - delete: deletes lead 

this allows future-proof api conveniently well.