OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0 authorization protocol. It facilitates third-party apps(clients) in verifying user's identity as well as accessing their basic profile information.

Now, let's familiarize ourselves with few terminologies before understanding how OIDC works:

Relying Party requests the Authorization Endpoint of OpenID Provider to authenticate the user and get user's authorization to access certain user information. After authenticating the user and obtaining authorization, the authorization endpoint sends an ID token and access token to the Relying Party.

These applications run on a server and send new page requests to the server for each action. These applications can store client secrets securely; hence, they are also referred to as Confidential Clients. The optimal authentication flow recommended for MPAs is Authorization Code Flow.

SPAs are modern web applications that loads the required section based on your action. These applications typically run on the client side after initially retrieving all the necessary resources from the server. They are also referred to as public clients, and they can't store client secrets securely as their entire source is on a browser. The suggested authentication flow for SPAs is the Implicit Code Flow.

In this flow, client(RP) requests Authorization Endpoint of OP to authenticate the user and get authorization to access certain user information. After authenticating the user and obtaining authorization, the authorization endpoint sends the ID token directly to the client. If requested, they also send access and refresh tokens. The client retrieves necessary user information from the ID token. Token endpoint is not used in this flow.

Native applications are the ones installed directly on the specific device. They are also known as public clients. They can't store their secrets securely, as they are directly installed onto a device, and the applications can be decompiled by anyone to access the client secrets. The flow recommended for native apps is Authorization Code Flow with Proof Key for Code Exchange (PKCE).

In this flow, the client(RP) generates a Code Verifier(a random string) and a Code Challenge (hashed version of the code verifier using any hashing method). Along with the authorization request sent to the Authorization endpoint of OP, the client also sends the code verifier. After authenticating the user and obtaining authorization, the authorization endpoint sends the Authorization Code to the client. At the token endpoint of OP, the client provides this authorization code along with the Code Challenge and the hashing method used to hash the code verifier. The token endpoint then dehashes the code challenge using the mentioned hashing method and checks whether the answer and the code verifier matches, to verify that it received the authorization code from the same client who sent authorization request.The token endpoint then provides the ID token and access token (if requested, refresh token as well). The client gets required user information from the ID token.