In our last blog post on web authentication, we looked at the SAML protocol. While SAML provides the capability to manage user identity between applications, it has largely been replaced by the more flexible and lightweight OAuth 2.0 protocol, which is the focus of this and the following blog posts.
What we have to say, what you want us to hear.
That’s how our blog works. It’s interactive. Let’s learn together.
Ultimately, there comes a point in almost every application’s life where it needs to either protect resources, or access protected resources. This used to be solved by simple client-server authentication, where a resource owner (an end user who owns specific data hosted on a server) would exchange credentials with a server to gain access to protected resources.
Around this time last year, I was developing a website for my wedding. The primary function of this website was to have guests RSVP on the site, so we could save a little money on postage and letterhead. I performed a thorough set of testing scenarios on Chrome, Firefox, and Edge, even employing the browsers’ mobile simulators. Everything seemed to work fine, so we sent out the invites and waited for RSVPs.
About a week afterwards, I got a text from my aunt; she couldn’t submit her RSVP! Why didn’t I catch this flaw in my testing?