Home » Understanding Digital Identity, Encryption, and OAuth 2.0 vs OIDC | by Prabesh Thapa | Oct, 2023

Understanding Digital Identity, Encryption, and OAuth 2.0 vs OIDC | by Prabesh Thapa | Oct, 2023

by Icecream
0 comment

Image by writer

Understanding ideas like digital identification, encryption, and authorization protocols is essential in right this moment’s digital panorama. This article goals to make clear these subjects and supply a complete overview.

In the digital world, a digital identification uniquely represents an entity, be it a person, group, or gadget. Just as bodily identification attributes like your title, picture, and private data assist establish you within the bodily world, digital identification consists of distinctive digital attributes equivalent to usernames, e mail addresses, biometric information, and digital certificates.

These digital identifiers are used to ascertain and confirm your identification within the digital realm, permitting you to entry on-line companies, talk securely, and conduct varied actions within the digital world.

This parallel between bodily and digital identification highlights the significance of safe and dependable identification strategies in each domains. This can manifest as usernames, emails, public keys, and even biometric information. These identifiers play a pivotal function in verifying one’s identification within the digital realm.

Encryption

  • Converts plain textual content into cipher textual content utilizing a mathematical algorithm and an encryption key.
  • It is a two-way course of.
  • Unlike hashing, it doesn’t end in a fixed-length output.

Hashing

  • Converts plain textual content into a set size string of chars referred to as hash.
  • An excellent hash ought to be a one-way course of, which means as soon as the information is hashed, it can’t be simply reversed to acquire the unique enter.
  • Used to verify information integrity
  • Fixed size

Let’s speak about just a few questions:

Is Bcrypt hashing or encrypting?

Answer: Even if the title contains crypt and suggests encryption, it’s hashing.

Is Base64 hashing or encrypting?

Answer: Neither, it’s encoding. It is an encoding method used to characterize binary information in an ASCII string format. It’s generally used for duties like encoding photographs in e mail attachments or embedding binary information in URLs.

Authentication: Verifying if a consumer is who they declare to be

Authorization: Verifying if the consumer has entry to sources the useful resource they wish to entry.

Tokens are pivotal in managing entry and identification within the digital world. They function information representations of a consumer’s identification or present entry to particular sources.

Various tokens exist, together with entry, refresh, session, ID, and CSRF. Each of them is mentioned under:

  1. Access token: The shopper makes use of this token to entry the Resource Server (API). They are supposed to be short-lived. These tokens are normally legitimate for just a few hours or a day. As it has a shorter interval, it can’t be revoked. Instead, we have now to attend for this token to trip.
    If you’re utilizing an entry token with a safe API, give the entry token a shorter trip to stick to safety greatest practices. For instance, the trip may be an hour.
    OAuth2.0 can be utilized for authorization, permitting you to entry a useful resource equivalent to an API endpoint for CRUD operations.
  2. Refresh token: The shopper makes use of the refresh token to get an entry token. To get a refresh token, functions sometimes require confidential shoppers with authentication. This is far longer-lived: days, months, or years. This may be revoked at any time.
  3. Session token: Token used to take care of stateful interactions between the shopper and server.
  4. ID token: Used strictly for authentication utilizing OIDC.
  5. CSRF token: Used to stop a particular sort of assault the place a consumer is tricked into performing on a unique web site with out their data.

Tokens don’t have to be within the type of JWTs (JSON Web Tokens). While JWTs are a preferred alternative for tokens resulting from their compact measurement, self-contained nature, and ease of use, they don’t seem to be the one possibility.

OAuth 2.0 and OpenID Connect (OIDC) serve distinct capabilities. OAuth 2.0 is primarily an authorization framework, whereas OIDC is geared in the direction of authentication. OIDC operates atop OAuth 2.0, which is constructed on prime of HTTP.

OAuth 2.0 and OpenID Connect (OIDC) are completely different techs constructed for various functions.

OAuth 2.0 is an open-standard authorization framework, not an impartial service. It allows you to grant delegated permissions and permit entry to particular sources equivalent to profile footage, emails, and cellphone numbers. It is learn as “oh-auth,” and it’s not the identical as AuthO, which is learn as “auth-zero.” One is a protocol specification, and the opposite is a product.

OAuth maintains a number of roles that assist facilitate and delegate entry to protected sources.

  1. Resource Owner (RO): An entity that may grant entry to a protected useful resource. The consumer could be a system or an utility. They solely have to personal the information within the useful resource server. For instance, I’m the useful resource proprietor of my Facebook profile.
  2. Client: The utility that desires to entry protected information on behalf of the useful resource proprietor. A cell app that desires to entry a consumer’s images on a cloud storage service. (e.g., net or cell app). This is a bit controversial. From the auth server perspective, any app tries to authenticate its shopper.
  3. Resource Server (RS): The server that hosts the protected useful resource. It verifies the token and offers entry to the useful resource. (e.g., server internet hosting file)
  4. Authorization Server (AS): Server liable for authenticating the useful resource proprietor and acquiring their consent to grant entry to the shopper. Once it is carried out, it points an entry token to the shopper (e.g., GitHub, Facebook, and Linkedin. They all function their very own authorization server)
  5. Authorization grant: Credential representing the useful resource proprietor’s consent to permit the shopper to entry their useful resource. There are various kinds of grant auth codes: implicit, shopper credential, and so on.
  6. Redirect URI: After the proprietor grants permission, the authorization server redirects customers again to the shopper as a particular URL with authorization data. This is usually referred to as callback URL
  7. Access token: Credential that represents that the authorization has been granted. They can’t do every little thing, solely the issues outlined within the scope
  8. Refresh token: Optional. Used to get a brand new entry token in case the earlier one expires
  9. OAuth scopes: It specifies the extent of entry a shopper may be granted. It is maintained and outlined within the authorization server
  • Simplicity: Version 1.0 was intricate resulting from its reliance on cryptographic signatures for every request.
  • Support: Initially tailor-made for server-to-server communication, model 1.0 has developed to accommodate a broader spectrum of shoppers, together with cell apps, net apps, and IoT gadgets, due to the introduction of assorted grant varieties.
  • Native help: Version 1.0 was not optimally suited to native cell functions. Version 2.0 addressed this by introducing PKCE (Proof Key for Code Exchange), enhancing the safety of authorizations.
  • Token-Based: While model 1.0 relied on signature-based authentication, model 2.0 adopted a bearer token method, streamlining the authentication course of.
  • Scope: Unlike model 1.0, which lacked a standardized technique for managing permissions and scope, model 2.0 introduces scopes, permitting for extra exact and granular entry management.

OAuth flows or grants, are a mechanism for shoppers to get credentials from authorization server (AS) to entry the useful resource server (RS). OAuth gives varied flows tailor-made for various eventualities, together with Auth code move, Implicit move, Client credential move, Auth code with PKCE, and Resource proprietor password grant move.

Usage: Used by an internet or server-side app that may securely retailer shopper secrets and techniques.

It’s relevant to net or server-side functions with the potential to securely retailer shopper secrets and techniques, particularly when management over each the back and front channels is maintained.

Here’s the steps to comply with:

  1. Client redirects the useful resource proprietor to the authorization server endpoint
  2. Resource proprietor authenticates and authorizer the shopper entry request
  3. Authorization server responds with authorization code
  4. Client exchanges an authorization code for an entry token

Usage: appropriate for client-side apps that can’t securely retailer shopper secrets and techniques

Here’s the steps to comply with:

  1. Client redirects to RO’s AS endpoint
  2. RO authenticates and authorizes the shopper entry request
  3. AS responds with an entry token

While the Implicit Grant move was as soon as extensively used, it’s now thought-about much less safe resulting from potential vulnerabilities (entry token ship through question param, no refresh token, and so on.). As a greatest apply, it’s really useful to steer away from using the Implicit Grant move. Instead, think about adopting the Auth Code Grant move with PKCE (Proof Key for Code Exchange).

This enhanced method gives a extra sturdy and safe technique for authorization, offering an added layer of safety in opposition to potential threats. Your utility’s safety and integrity are paramount, and making this swap is a step in the best path.

Usage: used for server-to-server communication (again channel solely). The Client Credential Flow is utilized for server-to-server communication, the place the shopper utility must authenticate itself to entry a protected useful resource. This move is suitable when there isn’t a direct consumer involvement and the shopper utility can securely retailer its personal credentials.

Here’s the steps to comply with:

  1. The shopper utility sends its personal credentials (shopper ID and shopper secret) on to the authorization server’s token endpoint.
  2. The authorization server verifies the supplied credentials and, if legitimate, points an entry token on to the shopper.
  3. The shopper can now use this entry token to entry protected sources on the useful resource server.

Usage: Enhanced model of auth code to guard in opposition to assaults

Here’s the steps to comply with:

  1. It is similar as an auth code grant however features a step to generate a problem
  2. The shopper generates a one-way hash
  3. The problem is used to show the possession of the unique code throughout a token change

Usage: This move is often used when the shopper utility has direct entry to the consumer’s credentials and might securely retailer them. It’s generally seen in legacy or inner programs the place increased safety measures is probably not required.

Here’s the steps to comply with:

  1. The shopper utility prompts the consumer for his or her username and password.
  2. The shopper sends the consumer’s credentials (username and password) on to the authorization server’s token endpoint.
  3. The authorization server validates the credentials and, if they’re right, points an entry token on to the shopper.
  4. The shopper can now use this entry token to entry protected sources on the useful resource server on behalf of the consumer.

OpenID Connect is devoted to authentication, providing a standardized method to areas the place OAuth 2.0 leaves room for interpretation, equivalent to scope and endpoints.

It extends OAuth 2.0, which permits shoppers to confirm the identification of the tip consumer and procure fundamental profile data.

Some key issues we should always bear in mind about OIDC are:

  • OIDC extends OAuth 2.0.
  • OpenID is an easy identification layer on prime of OAuth 2.0.
  • It permits shoppers to confirm the identification of the tip consumer primarily based on the authentication carried out by an Authorization Server, in addition to to acquire fundamental profile details about the tip consumer.
  • OIDC usually makes use of JSON Web Tokens (JWTs).

OAuth primarily facilitates useful resource sharing and entry, whereas OIDC focuses on consumer authentication. Its major goal is to offer identification verification throughout a number of web sites.

When utilizing OIDC to log in to an internet site, you’re redirected to the OpenID website for authentication. Once authenticated, you’re then redirected again to the unique web site. For occasion, when you choose to check in with Google, you’ll first encounter the Google login type. Upon profitable login, you’ll be directed again to your net utility.

This redirection course of ensures you obtain a safe JWT token for additional authentication and authorization.

The choice to make use of OpenID Connect (OIDC) or OAuth 2.0 is dependent upon the particular necessities of your utility. Here are just a few use instances:

Simple login auth

  • Identity: OIDC
  • Type: Authentication

Single sign-on throughout websites

  • Identity: OIDC
  • Type: Authentication

Mobile app login

  • Identity: ODIC
  • Type: Authentication

Delegated authorization

  • Identity: OAuth.20
  • Type: Authorization

Here are some suggestions on the place to make use of what move:

  1. Auth code move
  • Usage: Suitable for net functions or server-side functions that may securely retailer shopper secrets and techniques. This applies when you’ve gotten management over each the back and front channels.
  • Example situation: A conventional net utility with a backend server, Native app like cell apps.

2. Implicit move

  • Usage: Appropriate for client-side functions that can’t securely retailer shopper secrets and techniques. This applies if you solely have entry to the entrance channel, however not the again channel.
  • Example situation: A Single-Page Application (SPA) or a cell app.

3. Client credential move

  • Usage: Used for server-to-server communication the place the shopper can securely ship shopper credentials (shopper ID and shopper secret) to the Authorization Server’s endpoint.
  • Example situation: Communication between two servers or backend companies (API to API), daemons

4. Auth code with PKCE

  • Usage: An enhanced model of the Auth Code Flow, notably designed to guard in opposition to sure assaults.
  • Example situation: Mobile apps, native apps, or any situation the place you wish to add an additional layer of safety to the authorization course of.

5. Resource proprietor password grant move

  • Usage: Typically, for backend programs the place the useful resource proprietor (consumer) trusts the shopper with their credentials. This move is taken into account much less safe and ought to be used sparingly.
  • Example situation: Internal programs or legacy functions, native apps, headless shoppers like CLI apps

Remember, the selection of OAuth 2.0 move is dependent upon your utility’s particular necessities and safety concerns. It’s important to grasp the strengths and weaknesses of every move to make an knowledgeable choice.

Here are among the use instances and their really useful move varieties:

Web apps wish to entry API (FE + BE)

Flow sort for use

  • Authorization code move
  • Hybrid (implicit + code move)
  • Can add a refresh token move
  • Machine-to-machine move

Mobile apps

Flow sort for use

SPA

Flow sort for use

  • Authorization code grant move

CLI apps or Daemons

Flow sort for use

API-to-API

Flow sort for use

  • Client credential move
  • User might be in trusted programs

SSO with third-party service

Flow sort for use

  • Better combine with OKTA/Auth0/PingID

In wrapping up, it’s evident {that a} clear distinction exists between the utilization eventualities of OAuth 2.0 and OIDC. As engineers, we should discern these variations and apply them judiciously in keeping with our particular wants.

This nuanced understanding empowers us to navigate the digital panorama successfully, guaranteeing that our functions are safe and purposeful. Remember, it’s not about circumventing the use case however quite about leveraging the best instrument for the job.

I hope this overview of digital identification, encryption, OAuth 2.0, and OIDC has supplied you with worthwhile insights into securing your on-line interactions. Understanding these ideas is important in right this moment’s digital panorama.

Thank you for taking the time to learn our article! If you discovered this data useful, don’t hesitate to depart a remark and think about sharing it with others who would possibly profit from it.

Stay protected and safe in your digital endeavors!

To debug OIDC requests:

You may also like

Leave a Comment