Being a Multi-Factor Authentication and Authorization platform, LaunchKey implementers expect the platform to be secure.
From day one, LaunchKey was built with security as the primary driving factor. There's no use adopting a next generation
authentication system if it's not secure. When iovation set out to build the current generation of the LaunchKey API,
there were number of factors that affected the eventual selection of LaunchKey cryptography methodology.
- It must be generally recognized as an established and secure methodology for cryptography that has withstood the
scrutiny of peer review.
- It must be an industry standard for cryptography to ease implementation and reduce complexity within the LaunchKey
- It must be future proof. Future proof in this context would be defined as:
- Allowing the addition and removal of algorithms as they become mature enough to adopt or poor enough to abandon respectively.
- Allowing for increased cipher strength without requiring changes to our API, SDKs, or Subscriber implementations.
- Implementors should be required to utilize an acceptable minimum in regards to algorithm and cipher strength but
should be allowed to increase the security strength by choosing more complex algorithms and/or increased
be used for cryptography in the LaunchKey API. Some of all of the JOSE standards are used in established protocols
like OAuth, OpenID, and FIDO UAF.
How those standards are utilized within the LaunchKey API can be found in the sections below:
LaunchKey links to user contributed code as a resource to its community. LaunchKey does not in any way
guarantee or warrant the quality and security of these code bases. User contributed code is supported by the
creators. If you do find a link from the site to user contributed code that is malicious or inappropriate in any
way, please report that link to LaunchKey immediately and we will investigate the claim. Submit any issue to
LaunchKey support at https://launchkey.com./support.