Over the past articles, we have been exploring the world of the middleman (Api). We have been sufficiently able to break the concept down describing what it is, the advantages it presents, how to make it secure and the tools used for assessing its security posture. In this article, we are going to explore two important frameworks put to use in ensuring authentication and authorization to the middleman, but before we dive in, I will describe both authentication and authorization means, as it causes a lot of confusion in technology circles.

Authentication verifies the identity of a user or service trying to access a resource to determine if they indeed are allowed to access this resource while authorization, which can be seen as a step after authentication seeks to determine the access rights of the user or the resource. In simple terms both concepts can be viewed as an individual trying to gain access to a building, he is first checked at the gate if he is a legitimate resident of the building (authentication), after this step the gatekeeper now determines the rooms, he can access in the building and those he cannot (authorization).

Open authorization (oauth) is a widely adopted authorization protocol that allows a user to provide an application access to a protected resource without exposing the user’s credentials. It does this by providing a resource an access token via an authorization server, which can be used to access resources on the resource server, without revealing the user’s credentials. A real-world case study around the framework works is detailed below: Say Jon a content writer wants to aggregate all his content spread across several social media websites in a central platform “go-create”, he will login to his go create account and initiate the integration request. Let’s say he wants to integrate with twitter first, he will click on the twitter integration button which will take him to the login page of the twitter authorization server where “go-create” app supplies its pre-registered id and callback url, then the authorization server prompts the user to grant the required access to the “go-create” app. After the required access has been granted, the authorization issues an access token (which contains the resources the user has granted access to), this is then used to query the resource server to fetch the required data needed to be populated on the “go-create” app.

Source: Okta.com

Open ID connect (OIDC): is an authentication layer that was built on top of oauth. It enables Clients to acquire basic profile information about the End-User in an open and REST-like manner, as well as to confirm the End-identity User’s based on the authentication carried out by an Authorization Server. All types of clients, including Web-based, mobile, and JavaScript clients, can request and receive data about authenticated sessions and end-users over OpenID Connect. When it makes sense for them, participants can employ optional capabilities like identity data encryption, finding OpenID Providers, and session management thanks to the expandable nature of the specification suite.

TL;DR

Oauth and openid connect are frameworks used in authenticating and authorizing access to restricted resources via Api. Oauth employs the use of access tokens to access restricted resources on the resource server, while openid connect is an authentication layer built on the oauth protocol to verify identity.

I trust this article, however, brief gives an understanding of the contribution of these protocols in further securing the “middleman”