API Security
From ePrize Developers Wiki
(New page: TODO: organize and explain. Use SSL with basic auth and the {apikey} from a trusted computer or nothing except the {apikey} from an untrusted computer. The {apikey} only gives them access...) |
|||
| Line 3: | Line 3: | ||
Use SSL with basic auth and the {apikey} from a trusted computer or nothing except the {apikey} from an untrusted computer. The {apikey} only gives them access to a subset of the API that we want to make available to Flash. What's kind of funny is the subset API is the entire API at the moment. This mirrors exactly what TB2 does right now -- {apikey} is like a deploy path. | Use SSL with basic auth and the {apikey} from a trusted computer or nothing except the {apikey} from an untrusted computer. The {apikey} only gives them access to a subset of the API that we want to make available to Flash. What's kind of funny is the subset API is the entire API at the moment. This mirrors exactly what TB2 does right now -- {apikey} is like a deploy path. | ||
| - | --- | + | ---- |
| + | |||
| + | anti-botting protection with CAPTCHA. | ||
| + | |||
| + | ---- | ||
The draft I'm pasting below speaks to SSL mutual authentication. We | The draft I'm pasting below speaks to SSL mutual authentication. We | ||
Revision as of 13:20, 2 March 2009
TODO: organize and explain.
Use SSL with basic auth and the {apikey} from a trusted computer or nothing except the {apikey} from an untrusted computer. The {apikey} only gives them access to a subset of the API that we want to make available to Flash. What's kind of funny is the subset API is the entire API at the moment. This mirrors exactly what TB2 does right now -- {apikey} is like a deploy path.
anti-botting protection with CAPTCHA.
The draft I'm pasting below speaks to SSL mutual authentication. We probably won't use that outside of large customers with their own security teams, so we probably don't want to include any of that, although I'd like to leave it as an option eventually.
The relevant text is below:
AUTHENTICATION
Many RTI method calls require privileged access to Toybox functionality. Such calls must be authenticated over the HTTPS protocol.
The recommended authentication technique is mutual authentication, in which the client application and Toybox promotion site exchange digital certificates. Only recognized and trusted client certificates will be permitted to complete the request successfully. This technique has the advantage over password-based authentication in that it prevents disclosure of a secure password to unauthorized parties.
To implement mutual authentication, you must first request a certificate from a trusted certificate authority, then supply a copy of this certificate to your Account Services team. Finally, configure your application to include this certificate on outbound HTTPS requests. Your Account Services team will notify you when authentication is ready for testing.
For applications that cannot support mutual authentication, Toybox RTI also supports basic authentication over HTTPS. For use of basic authentication, a secure login/password will be supplied on request.
