Posted on

What D’Hack Is DPoP?

OAuth2.0/OpenID connect is considered the fastest-growing protocol used by many application developers for access delegation and single-sign-on. This is due to its flexibility and high security compared to other protocols in the market. In contrast, the world is full of hackers who are desperately looking for flaws that you make when developing an application. Single Page applications or public clients which do not use MTLS secure transport layers are considered to be the most vulnerable source of an attack. 

Standard Token Flow

Despite the application type, the standard OAuth2.0/OpenID connect flow is similar to the below diagram (Figure 2). There are three actors involved: Client, Resource Server, and Authorization Server. The client will initiate the authorization request. Upon user authentication, the authorization server will issue an access token and refresh token for the user with an expiry time. Then, the client can use these tokens to access the protected resource from the resource server.

Posted on

Dive Into OAuth Grant Types and OpenID Connect Flows

In my last article, you could read about the differences between OAuth, SAML, and OpenID Connect. Today I want to continue the topic. We will dive deeper into the processes of authentication and authorization offered to us by respectively (OpenID Connect) and (OAuth). However, we will start with a few words about the naming conventions in both.

GrantTypes vs Flows — Semantic Difference

In general, both terms are correct and can be used simultaneously. Both of them describe the same thing – a process of obtaining an Access Token. Just keep in mind that the term “Grant Type” is more strongly related to OAuth, while the term “Flow” is more related to OpenID Connect. As a side note, I can add that the term “Flow” rarely occurs in the OAuth specification.