Nearly a decade ago, the cyber industry was toiling over how to enable access for users between applications and grant access to specific information about the user for authentication and authorization purposes. Enter authorization-focused OAuth 2.0 and authentication-focused OpenID Connect (OIDC).
In the last decade, organizations adopted OAuth and its companion OIDC to enable customers and personnel the fast, secure access they demand. As the current industry standard, OAuth provides secure, third-party, user-agent, delegated access. Read on for a look into the terminology, dynamics, and advancements presented by OAuth.
Also Read: Passwordless Authentication 101
Table of Contents
Authorization vs. Authentication
Possibly misused more than any two terms in networking, authorization and authentication represent unique security processes of identity and access management. The below table touches on the critical differences:
| Authorization (OAuth) | Authentication (OpenID Connect) |
|
|
Also Read: 5 Tips on Using OAuth 2.0 for Secure Authorization
OAuth terminology
Resource Owner
In a world of data, users and the applications they trust contain valuable resources.
Examples include anything from personally identifiable information (PII) to proprietary secrets, but what’s critical to most everyone is that data stored in the application is only accessible to the user–unless other users or applications are authorized. The user in the OAuth protocol is known as the resource owner.
Client
In the OAuth flow, a client represents a third-party application that seeks access to the resource owner’s information. In a universe of applications, all digital users have interacted with client applications that require your basic information for registration. Alternatively, if you don’t want to plug in all of your information, clients will offer you the option of registering by logging into another platform like Gmail or Facebook.
Also Read: Application Security Vendor List for 2021
Resource Server
A resource server is a name given to the primary application responsible for providing the pertinent information to the client application. The primary application uses an API to manage communication and any exchanges that would enable the client to access the resource owner’s information.
Authorization Server, Grant, and Code
After being redirected to the resource server’s login page, users are presented with any additional security questions and the question of consent via the third-party’s authorization server. If consent is confirmed and the user wants the client to access the resource server’s information, an authorization grant with a specific authorization code outlining the request parameter transfers along with the user to the client’s callback page, also known as the redirect URI.
Redirect URI
The redirect URI, or callback, is the client page where users land after the client has received the authorization code. To the user, this is the end of the line. They’ve successfully used their existing application access to register for a new application, and they’re free to start using the client’s service.
Tokens
The OAuth flow boils down to the hunt for and exchange of tokens. Tokens are unique identifiers that represent authorization and authentication capabilities in a digital signature. For authorization, the OAuth flow ends with the client exchanging authorization code for an access token, also known as a bearer token. For authentication, the OAuth flow ends with the client exchanging authentication code for an ID token. In both cases, the tokens are provided by the resource server’s API and used by the client for authorization and authentication purposes.
- Access Token: used to authorize access to specific information about the user
- ID Token: used to authenticate and grant access to a user
Also Read: Protecting Against Solorigate TTPS: SolarWinds Hack Defenses
Scopes
In the OAuth flow, scoped information–also referred to as just the scope–is the parameters of the specific access granted to a client. Most scopes ask for your basic profile information or contacts, but digital users will also remember the more extensive requests giving a client access to post on your behalf and change your profile. Developers implement pre-set scope requests so that when a resource owner initiates the OAuth process, the authorization server knows what information is requested.
Also Read: Common IT Security Vulnerabilities – and How to Defend Against Them
Before OAuth 2.0
As the name suggests, OAuth 2.0 was designed to replace a previous protocol (OAuth 1.0) aimed at solving the problem of delegation authorization. The use of simple authentication and stateless protocol meant minimal security and repetitive logins for personnel and customers using the application. On the other foot, OpenID predates the development of OAuth and was initially used as an alternative to SAML 2.0 for single sign-on (SSO) and cross-domain identity federation.
Also Read: Mobile & Smartphone Security Threats for 2021
The OAuth flow
The OAuth flow breaks down into five distinct steps.
1. Resource Owner Directed to Authorization Server
Your everyday resource owner (user) stumbles upon a new application (client) and decides they would like to “login with x,” where x could be Facebook, Twitter, Gmail, etc. The resource owner can directly register with the client’s service without replugging their personal information for the new account.
The resource owner is then directed to the authorization server and asked to submit credentials. Virtually, the client request to the authorization server includes the redirect URI, needed response type, and scope
2. Credentials Submitted and Consent Requested
The resource owner confirms their credentials but isn’t redirected immediately back onto the client’s server. First, the resource owner receives a consent authorization where the user can either grant or deny the client to access specific information like profile information, contacts, pictures, and more. Without consent, the process ends here because the client-server needs the appropriate permission to move forward with its request.
Also Read: Guide to Getting the Right Single Sign-On Solution
3. Resource Owner Redirect to Client’s Callback
When the resource owner has granted consent, the user lands back on the client’s redirect URI, and from their perspective, the registration is complete. Behind the scenes, confirming consent also sends back to the client-server authorization code needed to complete the remainder of the process.
4. Client Exchanges Authorization Code for Access Token
The client can now call the resource server’s API with the authorization code in hand. The code itself is worthless beyond the API being able to understand and verify the request. Once confirmed as a legitimate authorization code, the API delivers back to the client what it ultimately required: the access token.
Also Read: How to Control API Security Risks
5. Resource Server Grants Access
The access token can is now usable by the client application to access the scoped information when needed. The resource owner who initiated and consented to the client registration process via a third-party account can now access the client application. The client application now has access to essential information about the user to create the account, and other scoped access like for profile or mobile contacts only eases integration of resources for both applications.
OAuth communication: Best of both worlds
OAuth combines two forms of activity when processing an authorization request that maximizes both user-friendliness and security. While developers can configure OAuth into only a few steps, the current five-step flow is the best of both worlds because it uses front and back-channel communication.
Front-Channel Communication
Front-channel communication is communication between two or more parties that rely on intermediaries like a browser for redirects. Front-channel communication presents a vulnerability in the form of an observable protocol. Keeping secrets in the JS or HTML of the web app means that anyone could inspect the webpage and breach the confidential information from the publicly visible source code.
The first three steps in the OAuth flow are completed via front-channel communication because the information involved doesn’t spoil anything, and the login and consent pages are more user-centric.
Also Read: How to Prevent Password Encryption Exploits
Back-Channel Communication
Back-channel communication is when two or more parties rely on a direct connection with standard protocol-level proxies. Unlike front-channel communication that relies on an intermediary like a browser in the case of OAuth, back-channel communication uses HTTP and API requests server-to-server. This communication protocol means the traffic will be SSL encrypted and highly secure.
Between steps three and four, a malicious actor with monitoring capabilities could steal the authorization code and attempt to exchange it for the access token intended for the client-server. The actor’s speed would need to be almost instantaneous, but good news, it’s not possible in the OAuth protocol. Because the authorization code is attached to the client-server (produced the initial request), the malicious actor needs the server key. This additional check ensures that invaluable tokens are only exchanged for authorization codes by legitimate clients.
Also Read: SASE: Securing the Network Edge
Why OAuth?
We use OAuth to address cross-site and application access when users are working with a range of applications. Today’s world of SaaS applications and user connectivity wouldn’t be possible without the development of OAuth. Benefits of OAuth implementation broadly fall under user-friendliness and secure access.
User Friendliness
Instead of requiring users to relog into applications, which can bog down customers and staff, OAuth generally makes life easier for users. Implementing OAuth means users can save time and resources when using multiple applications. Developers responsible for constructing the user interface offer standard request language and outline the scope of the request. The OAuth protocol enables users to grant access to a limited scope.
Secure Access
The prospect of users and staff managing dozens of account credentials presents a vulnerability for organizations. Luckily, OAuth offers a secure gateway for users and organizations to do just that with minimal security risks. The nature of limited scope, such as access to resources or an expiration time, provides all parties a more structured accountability system for information sharing. Additionally, OAuth can share data without releasing personal information and utilizes cryptographic SSL encryption to save user access tokens on a back-channel securely.
Also Read: Best Password Management Software & Tools
Misuse of OAuth for Authentication
OAuth 2.0 was recognized for its value and adopted in a clip for authorization and authentication. The problem: OAuth addresses delegated authorization. Instead of just authorization purposes, developers everywhere started implementing the OAuth protocol into common authentication mechanisms like simple logins, SSO, and mobile application logins.
The OAuth flow determines if your access token is adequately scoped and legitimate, followed by a grant of access to specific user information. When used for authentication, developers were stuck modifying OAuth to request more information than the authorization mechanism provided. Rather than letting developers run free to devise their unique OAuth supplement for authentication, welcome OpenID Connect to the party.
OpenID Connect (OIDC)
OpenID Connect (OIDC) is not a separate protocol; instead, it’s an added layer to the protocol that adds use cases for authentication where OAuth fails. Even before the development of OAuth 1.0, OpenID was working as a solution for authentication. With the market adoption of OAuth 2.0 and its ungermane use for authentication, OIDC has become a natural addition.
OpenID Connect specifically exchanges authorization codes for an ID token and can request more information via the Userinfo endpoint. OAuth and OpenID Connect both require a standard set of scopes and have standardized protocols for industry implementation. Together, the two standards enable a client-server to request both access and ID tokens, eliminating the need for additional configuration of OAuth.
OpenID Connect in the OAuth Flow
Including the OIDC changes little for the OAuth flow, with the only differences being the initial request and result. When a resource owner registers for a new application, the client’s request to the resource server previously included a redirect URI, response type, and scope. The callback and response type (code) remain the same, but the scope is to OpenID profile, which combines OAuth and OIDC request needs.
The flow continues with the resource owner submitting their credentials for the third-party app and consenting to the client’s authorization and authentication capabilities. From there, the client-server uses their authorization and authentication code in exchange for the access and ID tokens.
Also Read: Tokenization vs. Encryption: Which is Better for Protecting Critical Data?
The Rise of JSON Web Tokens (JWTs)
The most popular token in the authentication game is the JSON Web Token (JWT). JWTs are self-contained, meaning they include all pertinent information about the user’s access rights, which the application can verify for subsequent use by the user. More compact than XML and SAML, JWT can use an RSA or ECDSA public/private key pair and includes a digital signature. With a digital signature, the token can be independently verified by the application without talking to the authorization server.
OAuth: Advanced authorization
OAuth is about enabling secure cross-platform access for users and organizations. OAuth 2.0 grants access to your API and shares the extent of user data for other systems; OpenID Connect ensures the login of users and initial access across accounts. Together, these two innovations are not only what we wanted ten years ago but what we needed for an age of extended connectivity and reliance on applications.
IETF is currently in the draft phase for OAuth 2.1 standards.
Also Read: Best IAM Software
