Date and Time: 2023-10-20 16:27 Status:LearningIT Tags:API, Authentication and Authorization

OpenID Connect

OpenID Connect (OIDC) is an authentication protocol that adds an identity layer on top of OAuth 2.0. It helps securely authenticate users and enables applications to obtain user information from identity providers. OIDC is often used for Single Sign-On (SSO) scenarios, where a user only has to log in once in order to access multiple applications.

OIDC Components

OpenID Connect introduces several key terminologies and concepts that are essential to understand. These new terminologies include:

• Identity Provider (IdP) or OpenID Provider (OP): An Identity Provider is a service that authenticates users and provides identity information to relying parties (RPs) or client applications. The IdP is responsible for verifying the user’s identity.
• Relying Party (RP): A Relying Party, also known as a client application, is a web or mobile application that relies on the Identity Provider for user authentication and identity information. The RP requests authentication and user information from the IdP.
• End-User: The End-User is the person who interacts with the Relying Party and the Identity Provider. In OIDC, the End-User is the entity whose identity is being authenticated and whose information is being accessed.
• Identity Token (ID Token): The ID Token is a JSON Web Token (JWT) issued by the Identity Provider after a successful user authentication. It contains information about the authenticated user, such as their user ID and name. The ID Token is the primary extension that OIDC makes to OAuth 2.0 to make authentication possible.
• Claims: Claims are user attributes or data points related to the authenticated End-User.

OIDC Steps

Step 1: Client registration

Before any OIDC interaction takes place, the Relying Party (RP) must be registered with the Identity Provider (IdP). During registration, the IdP provides the client with a client_id (a public identifier) and, optionally, a client_secret (a private key). The latter is often used for confidential clients (like web applications) to authenticate themselves to the IdP.

Step 2: Authentication request

Authentication begins when the End-User decides to log in using a third-party provider, such as Google or Facebook. OIDC makes an authentication request by relying on the authorization server as specified in the OAuth 2.0 specification, but it uses extension parameters and scopes defined by OIDC to request that the End-User be authenticated by the resource server. In this case, the resource server is an OIDC provider to the client. Some of these extension parameters are:

• Scopes: The client specifies scopes, which determine the type of information (“claims” in OIDC terms) the client wants. openid is a mandatory scope for OIDC, but others—such as profile, email, or address—can also be requested.
• Response Type: This parameter indicates what kind of authorization the client is seeking. For OIDC, the value is typically code, which implies the client wants an authorization code that can later be exchanged for an ID Token and possibly an access token.
• State: This parameter holds a random value generated by the client to prevent cross-site request forgery (CSRF) attacks. The IdP will send this value back in the response, allowing the client to ensure the validity of the response.
• Nonce: This random string is another security measure that will be included in the subsequent ID Token. The client can then verify the token’s authenticity and confirm that it wasn’t reused.

Step 3: User authentication and consent

User authentication happens via the Identity Provider. The End-User is redirected to the IdP, which then authenticates the user, checks the requested scopes, and presents a consent screen if these scopes are not already granted to the client by the user.

Step 4: Authorization response

Upon successful authentication, the IdP redirects the user back to the client with an authorization code (if the response type was code in the authentication request) and a state. The state should match the one sent in the original request to ensure the integrity of the flow.

Step 5: Token request and response

The client is able to use the client_id and client_secret (optional) to authenticate itself with the IdP and exchange the obtained authorization code for tokens.

The IdP validates the provided authorization code and returns an ID Token, as well as an access/refresh token pair.

Step 6: UserInfo endpoint

The client uses the UserInfo endpoint when it needs more information (i.e., claims) about the End-User. The client sends the access token as a bearer token to the resource server, and the requested information within the granted scopes is returned to the client.

OAuth 2.0 and OpenID Connect

OAuth 2.0 and OpenID Connect

While OAuth 2.0 is about resource access and sharing, OIDC is about user authentication. Its purpose is to give you one login for multiple sites. Each time you need to log in to a website using OIDC, you are redirected to your OpenID site where you log in, and then taken back to the website. For example, if you chose to sign in to Auth0 using your Google account then you used OIDC. Once you successfully authenticate with Google and authorize Auth0 to access your information, Google sends information back to Auth0 about the user and the authentication performed. This information is returned in a JWT. You'll receive an access token and if requested, an ID token.

OAuth 2.0 is an authorization framework that defines a token-based authorization process for how third-party applications can get consented access to users’ data. OAuth 2.0 is a very powerful protocol for user authorization, but it does not define a clear and secure way to handle user authentication.

The OpenID protocol was introduced in 2005 as an open standard for single sign-on (SSO) and decentralized user authentication. It allowed users to log in to multiple websites using a single digital identity. An example of this type of flow is logging in to multiple websites using a Google account. OpenID defines how user authentication can be simplified, but it does not specify how user information should be securely exchanged between the client application and the identity provider.

The OpenID Foundation realized the need to integrate authentication into OAuth 2.0, and in 2014, they released the OpenID Connect protocol.

**OAuth 2.0** provide us with token-based authorization process
OpenID Connect add authentication features to OAuth 2.0
 
**OIDC** builds on top of OAuth 2.0 and adds authentication and user information features. This solves the two problems highlighted earlier.

By combining the two, developers can leverage the authorization capabilities of OAuth 2.0 while obtaining verified user identity from OpenID Connect.

To achieve this synergy, OpenID Connect introduces new endpoints and token types to the OAuth 2.0 framework. It extends the standard OAuth 2.0 authorization flow by adding the ID token as an additional response. The ID token contains essential user information, allowing the client application to establish the user’s identity with confidence.

One of the key advantages of using **OAuth 2.0** and **OpenID Connect** together is the ability to implement **single sign-on (SSO)** across multiple applications.

Once a user has authenticated with Identity Provider (IdP) or OpenID Provider (OP), subsequent requests to other applications that support OpenID Connect can leverage the existing session. This eliminates the need for the user to log in multiple times.

These protocols provide standardized mechanisms for handling authentication and authorization, reducing the complexity of implementation and promoting interoperability across various systems and platforms.

Link to original

OpenID and JSON Web Tokens

JWTs contain claims, which are statements (such as name or email address) about an entity (typically, the user) and additional metadata. The OpenID Connect specification defines a set of standard claims. The set of standard claims include name, email, gender, birth date, and so on. However, if you want to capture information about a user and there currently isn’t a standard claim that best reflects this piece of information, you can create custom claims and add them to your tokens.

The OIDC middleware does not support JWTs signed with symmetric keys. Make sure you configure your app to use the RSA algorithm using public/private keys.

1. Go to Dashboard > Settings.
2. Click Show Advanced Settings.
3. Set RS256 as JsonWebToken Token Signature Algorithm and click Save.

OpenID Auth UseAuth

app.UseCookieAuthentication(new CookieAuthenticationOptions
      {
    AuthenticationType = CookieAuthenticationDefaults.AuthenticationType
      });
 
      app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions
      {
    Authority = "https://{yourDomain}/",
    ClientId = "{yourClientId}",
    SignInAsAuthenticationType = CookieAuthenticationDefaults.AuthenticationType,
    ResponseType = "token",
    Notifications = new OpenIdConnectAuthenticationNotifications
    {
  // OPTIONAL: you can read/modify the claims that are populated based on the JWT
  SecurityTokenValidated = context =>
  {
    // add Auth0 Access Token as claim
    var accessToken = context.ProtocolMessage.AccessToken;
    if (!string.IsNullOrEmpty(accessToken))
    {
      context.AuthenticationTicket.Identity.AddClaim(new Claim("access_token", accessToken));
    }
 
    return Task.FromResult(0);
  }
}
      });

Reference:

https://openid.net/developers/how-connect-works/ https://blog.postman.com/what-is-openid-connect/