Summary

The webpage discusses the implementation of OpenID Connect (OIDC) in ASP.NET Core Web API, focusing on the OIDC authentication flows and the roles of various tokens and codes, including Access Token, Authorization Code, ID Token, and Refresh Token.

Abstract

The article is the second in a five-part series that delves into the authorization flows of OpenID Connect (OIDC) and their application in ASP.NET Core Web API. It outlines the three primary OIDC flows: Implicit, Authorization Code, and Hybrid, explaining how each flow handles token and code exchanges between the client, authorization server, and resource server. The article emphasizes the importance of understanding these tokens and codes—Access Token, Authorization Code, ID Token, and Refresh Token—in securing authentication flows. It also highlights the security implications of each flow, noting the deprecation of the Implicit Flow in OAuth 2.0 due to security concerns, while maintaining its validity in OIDC under certain conditions. The Authorization Code Flow is presented as the most secure option, while the Hybrid Flow is considered an acceptable compromise between security and functionality. The narrative concludes with a teaser for the next blog in the series, which will cover technical details of OIDC implementation in ASP.NET Core Web API.

Opinions

The Implicit Flow is deemed insecure and has been deprecated in OAuth 2.0, but remains valid in OIDC when only an ID Token is requested via Form Post.
The Authorization Code Flow is regarded as the most secure OIDC flow currently available due to the one-time use of the Authorization Code and the exchange of tokens through back-end communication.
The Hybrid Flow is seen as a less secure but acceptable alternative when both an ID Token and a Refresh Token are required, as it combines elements of both the Implicit and Authorization Code Flows.
The article suggests that understanding the nuances of token and code exchanges is crucial for implementing secure OIDC authentication in ASP.NET Core Web API.
The reader is encouraged to anticipate the next installment of the series for a deeper dive into the technical configurations required for OIDC setup in ASP.NET Core Web API.

Implementing OpenID Connect in ASP.NET Core Web API (2/5) — OIDC Authentication Flows

In this blog we will discuss Authorization Flows which become the basis of OpenID Connect Authentication. We will also discuss the roles of, Access Token, Authorization Code, ID Token and Refresh Token at the end.

This is the second blog of a 5-part series on how to set up OpenID Connect (OIDC) in ASP.NET Core Web API. Click here to go to the first blog in this series.

In the previous blog, we set the stage, by discussing OAuth 2.0 and OpenID Connect and their differences.

We also finished listing three OAuth 2.0 Authorization Flows which OIDC uses to extend OAuth 2.0 to provide Authentication capabilities.

The three Flows are:

1 — Implicit Flow

2— Authorization Code Flow (or just Code Flow)

3 — Hybrid Flow

What is a Flow?

Consider a city with some roads interconnecting each other. A car that needs to drive from point A to point B can take multiple ways to reach the same destination, but of course, there can be different pitfalls in every available choice.

The same is true with an Authentication Flow. OAuth 2.0 provides multiple pathways for communication and a Flow is a choice of path we adapt to authorize a user.

Find below a diagram of OAuth 2.0/OIDC communication channels which all the above Flows traverse:

click here to go to the first blog in this series, for details on how the above “Flow” works.

You might wonder; if all the three Flows follow the same execution path, then what is the difference?

Well, the difference is:

Which Tokens/Codes are exchanged through “Front End Communication”?
Which Tokens/Codes are exchanged through “Back End Communication”?
How to secure a Flow is, based on the token/Code exchanges?

To understand the above Flows, first, we need to understand the Tokens/Codes involved.

So here we go!

Tokens/Codes

1 — Access Token

Access token is a reusable JWT encoded string, issued by the Authorization Server when a user is authorized/authenticated successfully. When received by the Resource Server and verified, the Resource Server must trust that the user is allowed to access restricted resources.

In the case of OIDC any further “Back End Communication” needs to be accompanied by Access Token. When expired, a Refresh Token is needed to renew an Access Token.

2 — Authorization Code (or just Code)

Authorization Code is a one-time use encrypted token, Issued by the Authorization Server when a user is authorized/authenticated successfully. When received by the Resource Server, it sends this code back to the Authorization Server through “Back End Communication” in exchange for an Access Token, and later uses Access Token for further “Back End Communication”.

3 — ID Token

A JWT encoded string, issued by the Authorization Server, when specifically requested, in addition to Access Token or Authorization Code, when a user is authorized/authenticated successfully.

4 — Refresh Token

A JWT encoded string, is issued by the Authorization Server when it is either specially requested when the user is authorized/authenticated successfully using “Front End Communication” or when the Authorization Code is exchanged for Access Token using “Back End communication”.

It has a slightly longer expiration time than Access Token. When received by the Resource Server, it is stored and sent back to the Authorization Server through “Back End Communication” to request a new Access Token when the older Access Token expires. Resource Server in return, a new Access Token and a Refresh Token are received.

Flows

Now that we have all the tokens explained, we should be able to understand the Flows a little better.

Let us know more about the three Flows we mentioned in the beginning:

Implicit Flow

1 — The client tries to access a restricted resource

2 — The client is redirected to the Authorization Server requesting Access Token or ID Token or both.

3 — Requested tokens are returned to the Client.

4 — The client stores the tokens locally and sends a copy to the Resource Server.

5 — Resource Server uses Access Token for “Back End Communication” with Authorization Server until Access Token expires.

6 — Access Token cannot be renewed here, and the Client must run the same authorization cycle once the Access Token is expired.

Since Access Token is exchanged through the client side, this makes this Flow quite insecure. If Access Token is hijacked the Client is compromised. That is why Implicit Flow has been deprecated for OAuth 2.0 and should not be used.

Implicit Flow is still valid for OIDC, as long as only ID Token is requested Through Form Post.

Authorization Code Flow (or just Code Flow)

1 — The client tries to access a restricted resource

2 — The client is redirected to the Authorization Server requesting a one-time use Authorization Code.

3 — The requested code is returned to the Client.

4 — The client sends the code to the Resource Server.

5 — Resource Server exchanges code with Authorization Server using “Back End Communication” and receives Access Token, Refresh Token, and optionally ID Token in return if requested.

6 — Resource Server uses Access Token for “Back End Communication” with Authorization Server until Access Token expires.

7— When the Access Token expires the Resource Server sends the stored Refresh Token to receive a new Access Token and a new Refresh Token.

Authorization Code Flow is the most secure Flow currently available, as the Access Token is never passed through “Front End communication” and Authorization Code is a one-time use token which even if hijacked cannot be abused due to the exchange of additional secret keys only through “Back End Communication”.

Hybrid Flow

Hybrid flow is a mix of Implicit Flow and Authorization Code Flow, where code is exchanged through “Front End Communication” along with ID Token.

1 — The client tries to access a restricted resource

2 — The client is redirected to the Authorization Server requesting a one-time use Authorization code and ID Token.

3 — The requested Code and ID Token are returned to the Client.

4 — The client stores the ID Token locally and sends the Code to the Resource Server.

5 — Resource Server exchanges code with Authorization Server using “Back End Communication” and receives Access Token and Refresh Token.

6 — Resource Server uses Access Token for “Back End Communication” with Authorization Server until Access Token expires.

7 — When the Access Token expires the Resource Server sends the stored Refresh Token to receive a new Access Token and a new Refresh Token.

Hybrid Flow is not as secure as Authorization Code Flow but is an acceptable solution as ID Token only contains User Profile details which is public information anyway.

Phew!!!

This is all we need to know about OIDC Authentication Flows (yes, we rebranded OAuth 2.0 Authorization Flows).

In the next blog in the series, we will review OIDC technical details such as:

What details are needed to set up a tenant at IDP?
How to access and read the IDP-provided OIDC discovery file?
What configurations are needed to implement OpenID Connect in ASP.NET Core Web API?

Click here to go to the next blog in this series.

🔔 Follow me for more content like this! 🔔

If you find this content helpful and want to show your support, you can buy me a coffee ☕.