In a recent blog post, I added a throwaway reference to the use of signed assertions as a better mechanism for interacting with the Oracle Identity Cloud Service REST APIs than the use of Client id/secret, though qualified it with ‘if you want to handle the additional complexity in your consuming client’. Reflecting upon this, I thought that perhaps it was worth trying to explain this ‘additional complexity’, since the use of signed assertions have a number of benefits; primarily that it does not require an exchange of sensitive information, as the private keys used to sign the assertion never need to leave the machine on which they are generated. In this blog post, I will delve deeper into what is required to leverage this authentication mechanism, for both clients and users.
In today’s environment where systems run in the cloud and so much business and personal activity occurs online, passwords are not strong enough by themselves to protect applications. Scandals about password breaches seem to happen on a regular basis. It’s easy to find many case studies where passwords have been compromised as a result of malware, email scams and other techniques. The key point is that no matter how strong our passwords, no matter how much we educate our users, there will be situations where people are caught off guard and click on the wrong link, look at the wrong email or open the wrong document. Once this happens, our passwords can be compromised.