The security of a website can make or break a business. Customers and clients expect websites and applications to have security in place. Software engineers need the ability to build applications securely by providing a Single Sign-On (SSO) experience. SSO allows users to conveniently log into an application by using a single set of credentials.

A great feature of this user experience is that the user gets to choose their method of logging in. Users can use biometric identity, phone number, password, digital certificate, two-factor authentication, or multi-factor authentication (MFA). Thanks to OAuth, users can use the same set of credentials across a myriad of sites throughout the day.

What is OAuth?

It is a standard that allows access to hosted resources via applications and websites. It is the existing method of authorization for most sites and applications today. Open Authorization 2.0 allows consented access to a client app.

Never compromise security
for convenience, choose both!

The abilities of the client app are restricted. The user’s credentials are never shared to gain access. OAuth 2.0 authorizes access to server-side apps, browser-based apps, and mobile applications.

The 2.0 version utilizes access tokens, often used in the JWT format. The JWT token format is broken down into three parts: header, followed by payload, ending in a signature. JWT claims are encoded as JSON objects containing key/value pairs. A security feature of an access token is the expiration date.

Framework roles

There are four roles in the Open Authorization 2.0 framework; the resource owner, client, authorization server, and resource server. The resource owner owns the resources that you would like access to. The client system wants to access the resources and must have the correct access token to do so.

The authorization server receives the request from the client system to access resources.

Access is granted after authentication is successful and the resource owner provides consent. Two endpoints are exposed by the authorization server.

This includes the token endpoint “/oauth/token”, and the authorization endpoint “/authorize”. Finally, the resource server is responsible for protecting a user’s resources and accepting requests for access from the client. The resource server returns the corresponding resources after accepting and validating the access token.

Down memory lane: A brief history

The story begins in November 2006 in a meeting about access delegation.

There were discussions on how to combine the usage of Twitter OpenID and the Twitter API. They agreed that there was no standard for API access delegation. The following year, a small group from Google wrote an open protocol proposal and released a final draft of Open Authorization 1.0.

Examples of OAuth

You can find an example of this framework on the log-in page of many modern sites and apps. Notice how the user interface asks you to log in using your credentials from another website? That is OAuth.

How OAuth works

Let’s say you want to log in to an online photo printing lab using your social media log in. This framework solves the issue of exposing your username and password to the photo printing lab. It lets you grant access to your private resources on one site to a separate consumer site. For example, you can grant the photo lab website access to your pictures using your social media credentials. Thanks to OAuth, you don’t have to register as a new user, saving you time.

Grant types

Developers decide which one of four flows is best to gain an access token; Authorization Code Flow, Resource Owner Password Flow, Implicit Flow with Form Post, or Client Credentials Flow. Authorization Code Flow uses the Proof Key for Code Exchange (PKCE) and mobile applications employ this. Resource Owner Password Flow is best for use by the most trusted applications, due to the need to provide your password and username on an interactive form.

Implicit Flow is no longer the most secure method. OAuth 2.0 documentation recommends discontinuing Implicit Flow for JavaScript and native applications. It is no longer recommended because of the risk of returning access tokens without confirming it was received by the client. Implicit Flow with Form Post involves the use of just the client ID rather than the client secret.

Implicit Flow returns the access token within the redirect from the authorization flow. Client Credentials Flow is employed for communication between machines. Examples of machine-to-machine communication include services operating in your backend, daemons, and Command-Line Interfaces. Client Credentials Flow authentication involves passing a client secret and client ID for a token.

Why is OAuth safe?

It allows developers to protect sites and applications against exploits. Open Authorization is integral to securely transmit information from user to server and vice versa. The framework is safe enough for use by giant companies such as PayPal, Facebook, Hewlett Packard, Netflix, Instagram, LinkedIn, Microsoft, WordPress, Spotify, and more.

The 2.0 framework provides a degree of safety that previously was not present.

Thanks to this framework, you don’t have to worry about compromised passwords because you want to use the same credentials on multiple sites. Open Authorization tokens only give access to a limited amount of personal data.

The difference between SAML, OpenID, OAuth 2.0

These three technologies are the most important for identity federation. Open Authorization 2.0 deals with the authorization of resources, while SAML deals with SSO and identity management. SAML does not require you to type in your credentials or renew them.

Security Mark-up Language differs from Open Authorization 2.0. SAML grants the user an access token that is good for one session.

OpenID allows you to use an SSO for many sites, while Open Authorization provides access without sharing your identity or secret credentials.

Open Authorization supersedes OpenID by allowing users to gain access to websites without forcing them to expose their credentials. It is comparable to the Flickr API, AWS API, and Google AuthSub protocols.

Keep in mind that Open Authorization 2.0 is a framework, not a protocol like its previous 1.0 version.

In an increasingly technologically-enabled world, high-level security is the standard. Single Sign-On is familiar and expected by most users. Many users feel safer online when they don’t have to sign up for a website to use its services.

The user can simply use credentials provided to the resource owner (website) they already trust.

Secure sign-on for you and your team

Working remotely? Teamstack helps you expand your enterprise. Teamstack is a platform that makes it feasible for your customers, employees, and clients to have a Single Sign-On experience. Users can sign in without a password.

Teamstack seamlessly integrates with at least 600 applications including; Slack, GitHub, Zoom, GoToMeeting, Mailchimp, Jira, among others.

The platform is a centralized location for a business owner’s productivity and organization. Teamstack makes it easy for your team to log into SSO-based platforms. It provides Single Sign-On via SAML, making all web applications completely secure. Teamstack also supports multi-factor authentication.

The platform makes it easier to keep track of your team members. One-click provisioning allows you to quickly add or remove a user from your organization.

Your workforce can access all applications from a single location whether it’s custom-built for your enterprise or in the cloud.

More than 750 teams rely on Teamstack. Companies utilizing Teamstack include; TNW, Capterra, VentureBeat, and Designmodo to name a few.