OpenID Connect and Oauth 2.0
Comprehending the Use Case
This is where we must first comprehend the use case: Are we using favorite social provider to create our identification or are we providing the application access to interact with the data when we use "Log in with favorite social provider"? Importing my Twitter account name and profile information differs significantly from sending direct messages as myself. As developers, we must be aware of the distinction and only request the rights we require.
Do You Know What’s Software Development Life Cycle?
Understanding what problems our tools are built to solve is the first step in making our apps more secure. The OAuth 2.0 Framework specifies overall authorization patterns but does not specify how to perform authentication.
The application uses OAuth to send a specific permissions request to a third-party system, known as an Identity Provider (IdP), which handles the authentication and delivers an Access Token indicating success.
Additional factors, such as SMS or email, may be required by the IdP, although this is outside the scope of OAuth. Finally, by default, the contents and structure of that Access Token remain unknown. This uncertainty ensures that Identity Providers will create systems that are incompatible.
Fortunately, OpenID Connect, or OIDC, offers some order to the chaos. It's an OAuth extension that introduces and precisely defines an ID Token for returning user data. When we use our Identity Provider to log in, it may now return specified fields that our applications can manage. The most important thing to keep in mind is that OIDC is really a simplified version of OAuth, not a substitute. It employs the same lingo and principles.
OpenID Connect Vs Oauth 2.0: Key Distinction
Standards and Their Dissimilarities
The key distinction between the two is that OAuth 2.0 is a framework for controlling authorization to a protected resource, such as an application or a set of files, whereas OpenID Connect and SAML are both federated authentication industry standards. That implies OAuth 2.0 is utilized in very different contexts than the other two protocols (examples below), and it can be used with either OpenID Connect or SAML at the same time.
- Enterprises can achieve user authentication and install single sign-on using either OpenID Connect or SAML on their own. Despite the fact that they both deal with logins, they have distinct advantages and disadvantages.
- OpenID Connect is based on the OAuth 2.0 protocol and employs an additional JSON Web Token (JWT) known as an ID token to standardize areas where OAuth 2.0 allows for flexibility, such as scopes and endpoint discovery. It focuses on user authentication and is commonly used on consumer websites and mobile apps to facilitate user logins.
- In contrast to JWT, SAML is not dependent on OAuth and instead relies on an exchange of messages to authenticate in XML SAML format. It's more typically used to allow enterprise users to log in to various applications with a single password.
Access Control and Scopes
The next most common blunder involves scopes or the permissions we ask for. Scopes are essentially how we create and apply fine-grained access control to certain resources, information, or activities in our system.
The scopes are described as OpenID, profile, email, address, and phone in the OpenID Connect definition and each gives access to that specific information. If you use a scope other than those, you've left the OIDC definition and are now dealing with general OAuth, which is where things get difficult.
For specific scopes, OAuth does not define naming standards, relationships, or access. In practice, this means that an admin scope can mean various things to different systems, assuming it even means anything. On the plus side, it implies that corporations like Google can create OAuth Scopes that are extremely structured and predictable.
On the downside, Github now has scopes called user, read: user, and user: email that provides read-only access to user profiles. In Android, the same issue occurred when you gave the Facebook app access to your contact list, which includes your SMS and call history. For specific scopes, OAuth does not define naming standards, relationships, or access.
In practice, this means that an admin scope can mean various things to different systems, assuming it even means anything. On the plus side, it implies that corporations like Google can create OAuth Scopes that are extremely structured and predictable. On the downside, Github now has scopes called user, read: user, and user: email that provides read-only access to user profiles.
In Android, the same issue occurred when you gave the Facebook app access to your contact list, which includes your SMS and call history.
Management of Claims
Next, we must consider claims carefully. Our Access and ID Tokens contain a name/value pair that is referred to as a claim. You might have a user id or email claim, for example, so that downstream applications can generate profiles or make judgments based on these. The aspect that's confusing is that the OAuth Core standard doesn't even include claims.
This is advantageous because we can define it as we see fit. Unfortunately, people will define them in whatever way they see fit. The JWT standard (RFC 7519) introduces the notion and outlines a basic structure, however, it does not establish any naming, structure, or other norms. Using OpenID Connect gives us a lot more security.
It specifies a basic set of claims for user information such as name, address, and other similar information. If we only utilize those and restrict access to the appropriate scopes, the user will be aware of the information they are sharing and programs will be aware of how to use it. Alternatively, when more claims are added, it's natural to want a user-unique identification.
If we are being careful, we'll employ an obfuscated primary key that has no external meaning. That might be a customer identifier, employee number, or even a Social Security Number if we're not careful. This is similar to how Facebook is grappling with the consequences of releasing too much information about a user's network via their API.
Alternatively, when more claims are added, it is natural to want a user-unique identification. If we're being careful, we'll employ an obfuscated primary key that has no external meaning. That might be a customer identifier, employee number, or even a Social Security Number if we're not careful.
This is similar to how Facebook is grappling with the consequences of releasing too much information about a user's network via their API.
When And For What Reason Should You Apply For A Grant?
The other most prevalent blunder has to do with the different OAuth grant types or flows. Authorization Code, Implicit, Resource Owner Password, and Client Credential are the four grant types that specify how an application can retrieve tokens from your OAuth server and are utilized in various use cases.
Code of Authorization
By default, the Authorization Code flow is the most powerful and secure. When the user is redirected to the Identity Provider to authenticate, the IdP returns a one-time user authorization code that expires after a short period of time. The Access Token is retrieved by the program using the permission code.
The crucial part is divided into two parts: To begin with, by the time the user sees the authorization code, it has already been used and cannot be used again. Second, the program stores the Access Token in the backend. Assuming the program is created safely, a malicious user will have to devise a new method of attack.
Because the user is likely to engage with the token(s), it's critical that our use cases reflect this. Allowing the send wire transfers to Russia scope in a banking app may be a terrible idea unless we have extra authentication factors in place to ensure that the appropriate person is utilizing it. That will come in handy the next time you misplace your phone.
As a result, when a user wants to offer trustworthy profile information to a third party but not necessarily access or rights to other systems, this is frequently employed in OpenID Connect scenarios. Because the basic concepts are the same and the implementation appears to be fairly comparable, the benefit for the same work is nearly identical.
Password for the Resource Owner
Resource Owner Password makes me nervous when compared to the prior grant kinds. The application redirects the user to the Identity Provider to enter their login and password in both the Authorization Code and Implicit flows. As a result, their credentials are never seen by the application.
The Resource Owner Password flow allows the program to receive and submit credentials on behalf of the user. If the program is malicious or even badly built, the credentials could be stored and the user's information compromised. As a result, you should only utilize it if you're creating apps that allow users to interface with ancient systems.
However, keep in mind that You're basically teaching people to put their credentials into applications they don't trust, which is a terrible habit at best and a security risk at worst.
Credential of the Client
The Client Credential grant type is intended just for server-to-server activities in the backend. Think of it as a server's account and password. In terms of concept, it's similar to how your app communicates to other backend systems like your database or Twilio.
The fact that your OAuth provider can return configuration information or other details within the token itself is a benefit. Finally, it does not enable OpenID Connect because there is no user involved.
Despite the fact that this entire piece has been about OAuth, you may have noticed that no code is included. The reason for this is straightforward: design decisions are still crucial. The best libraries in the world won't protect you if your scopes are too large, your claims include sensitive information, or you use improper flow for the environment.
Your users' data will be stolen, your applications will be susceptible, and your business will suffer as a result. Alternatively, if you understand your product's use cases and what your users are attempting to do, your software will be better, more secure, and you'll be able to keep the "We're sorry..." emails to a minimum.
To start your new project you can contact us!!