Understanding modern day Authentication with OAuth2 and OIDC

ℹ️ This post was written in the context of my employment at ARES. While it does not promote any software or solutions from which ARES or I will benefit off, it is written in a more cooperate tone.
The german version can be found at my company’s website.

Authentication is hard. Especially when the traditional concept of a trusted network becomes increasingly outdated with remote employees and the security aware concept of Zero Trust. Nowadays every entity composes a potential threat. Implementing authentication into every application (even into internal ones) becomes a significant overhead, consumes valuable development time, and drives up cost. We would like to give a top-level overview of modern authentication methods, where these can be used, how they can improve the security of offered services and how they can even help to improve the usability of services.

The need and pains of authentication

Authentication is needed everywhere. Today there are distinct accounts for every individual which hold personal information. With data becoming more and more valuable and sensitive, it’s a company’s duty to protect user data from unauthorized access. Failing this can result in a massive lost in trust and reputation while also eventually result in legal consequences. This also includes HR information and logged working hours of employees. Managing these information becomes increasingly difficult with the number of different applications deployed. Keeping employee’s data (such as address, accounting, and social information) safe, updated and in sync between multiple applications pose a considerable challenge, due to the duplicated data handling nature of these systems.

When offering services for end users the same problems occur. Users nowadays have lots of different accounts. When there is a change in their life, like moving to a new city, changing banks or an update in their relationship status, they are not likely to update all their information on every platform they use. Inaccurate data lowers the quality of the accumulated information and my also introduced cost due to an incoming service ticked caused by a failed bank transaction. In a well disingenuous system, there would be a central location where each and every app that needs user data can request them or even enriches them by adding additional information. A 3rd party application could request access to a user’s posts and contacts, do analysis on them, provide users insights about their contents, and offer recommendations for expending their network. There is an increasing awareness to the value of personal data and some users might not be willing to provide these information to any app. When users are promoted with lengthy registration process, for a new app, they are much more likely to discard dealing with the app compared to a quick an easy setup where they can log in with their existing accounts, like a Google account. The lack of an uncomplicated, quick sign-up process could lead to a significant reduction in the user adoption rate, which could, depending on the business model, reduce the generated revenue stream.
Beside the logical and business aspects of user authentication there is also the technical aspect.

As mentioned at the beginning, authentication is hard. Building it from scratch is only recommended in the rarest cases and when having skilled and experienced developers. They have to consider hashing, salting and storing credentials in a secure manner. There a plenty of news where companies, even large and reputable companies, faced data breaches, exposing credentials and sensitive personal information about their users. Developers can get 99% of the authentication process right but render their whole implementation vulnerable by making one mistake. Even when authentication is handled by an external library, developers have to consider things like security questions, password rests and 2 Factor Authentication (2FA) with services like One-Time-Passwords (OTP) and hardware tokens. They also have to constantly update and review the used library in order fix disclosed vulnerabilities and to prevent supply chain attacks. Complicating things even further, the combination of username and password is not considered best practice anymore, due to cumbersome nature and susceptibility to being stolen. That’s why companies like Google are researching and pushing new authentication methods, like passkeys, and want to get rid of the traditional password.

Considering and implementing all these aspects while designing and implementing an app introduces a considerable amount of business and application logic, especially if one decides to presume the path of a microservice architecture service. The good thing is that there are a lot of people facing this problem and that there are existing solutions to streamline, enhance and simplify the authentication process for every entity involved. The most promising and widespread approach are the OAuth2 and OIDC approach.

Introduction to OIDC and OAuth2

Both OAuth2 and OIDC provide concepts of how one can grant controlled access to specific resources. The OIDC specification restrictions its scope to only authentication, meaning it will only guarantee the legitimacy of the user through an external identity provider. Access control for limiting theses authenticated users to specific subset of resources is explicitly not part of OIDC and must be handled by the apps logic. This is helpful if there is no need for fine grained access control, if just the membership to the organisation must be assessed or if the app already has a system for fine grained access controls implemented. A prominent example is Kubernetes. The users authenticity can be provided via OIDC the access control is handled by Kubernetes RBAC system.

The OAuth2 authentication spec is mainly described in the rfc6749 and covers both authentication and authorisation. Therefore it is quite broad and even has some sub specification and several extensions. For simplicity, this article will only focus on the main aspects of this spec needed for understanding and implementing it. The key concept of OAuth2 is that it provides an authorization framework where the authentication is handled by an external provider, often called the authorization server, where the client (mostly an app or the browser) can request access to information of the resource owner (user) on behalf of that user to access protected resources.

The important aspect in OIDC and OAuth2 is, that the user does not log himself in on the main app or website, but is instead redirected to one of the many existing authorization provides like Google, Microsoft or Facebook. While logging in, the user can see the type of information that the client wants to access (called scope) and can either approve or decline them. By design the client and any external resource never gets to access the user’s credentials and the entire authentication logic is handled by the authorization server. So there is no need to store passwords or implement passwords resets and 2FA yourself.

The OAuth2 spec offers different authentication flows, called “grants”, designed for different use cases. The most common flows, and the ones covered in this article, are the Authorization Code Flow and the Client Credentials Flow.

The visualization below shows the Authorization Code Flow, which is the grant most used for interactive user Authentication. When the user visits a company owned Login-Page he can choose to Login with <My-Auth-Provider>. This button takes the user to the Login-Page of that provider where he can login and give consent to the requested information. On confirmation, the user is redirected back to the original site with an Authorization-Code embedded in the URL. Now the company app can use that Authorization-Code, together with other configuration parameters to request an access and refresh token from the Auth-Provider. Using that access token, the app/website can request information about that user or perform actions on behalf of that user, without ever knowing the user’s password. The allowed actions are limited to the degree that the user has agreed to in the beginning. The access token has typically has a very short lifespan and regularly expires. New access tokens can be seamlessly requested via form the authorisation server. This significantly reduces the risk of leaked or stolen credentials while also allowing to easily revoke a users-session.

Even if the theoretical procedures seem complex at first glance, the implementation is relative straightforward. In addition, this setup saves all the complexity required for a user registration process, password storage and reset, mail verification, 2-factor authentication, and maintenance. The app/website does not need to store any information about the user, since it can always request up-to-date information. So it does not need to worry that the address may be outdated. Due to the short lifespan of each access token (default is 2h), the users information security is also improved as the risk of session hijacking is significantly reduced. Only the original app can request a new access token with its configuration and the refresh token.

The second grant mentioned is the Client Credentials Flow. It is designed for use cases where no user interaction is needed and where both, client and resource server, is owned by the same entity. This method allows two application to communicate safely with each other, while also providing the advantages of short lived tokens and scoped access. This concept can be extended even further. With federation one can enable a trust relationship between two systems. When this is used there is no need for any credentials anymore. CI systems are ideal candidates for such a setup since it allows secure and low maintenance communication between systems like GitHub Actions to AWS or Azure.

Whats in for me?

The potential savings that can be achieved through OAuth2, especially in enterprises, are enormous. For example, using OAuth2 in conjunction with Microsoft 365 would allow a company to secure and manage all of its systems with one central user account, such as the existing Exchange/Microsoft account. Users would have significantly fewer passwords and techniques such as Single Sign On (SSO) could significantly reduce the average number of 12 daily logins (found out by security-insider.de) and the associated time required. Workers will be more productive and less annoyed by re typing passwords all day.

Upon termination of employment, the responsible parties only have to block one account instead of going through long lists of accesses and deleting them with the high risk of overlooking something. The onboarding of new employees is also significantly shortened because only one account needs to be created and the new employee can then access all the necessary systems. Because of these advantages, the reduced effort required for authentication, the additional security and the convenience for users, the use of OAuth2 continues to grow. Many applications and services such as Jira, GitLab and others already offer built-in support for OAuth2. Even if applications do not support this, such as internal wikis or applications that do not inherently provide authentication, this can be implemented with little effort.

The idea to offload the entire user management might sound a little scary at fist, specially if it is an external identity provider, but since OAuth2 and OIDC are well defined public specifications with a broad adoption there is no risk of a vendor lock-in. If a Microsoft or Google controlled identity store ist not an option, there is a wide range of alternative solution to implement an identity provider. Some of them fully open-source and self-hostable. Well established solutions are KeyCloak and DEX.

Especially in the cloud environment, with many microservices, where Zero Trust is becoming more and more standard, a Kubernetes application can be made OAuth2 ready with just one manifest and thus offer its employees and customers faster, more secure, and better services.

The whole idea of OAuth2 is to push the One Identity concept for each user. There should be no additional accounts, the user has a central authority with secure, reliable information and this identity will be authorized to access the necessary resources. This identity concept is provided by the OpenIdConnect (OIDC) standard, which is part of the OAuth2 specification.

If your company struggles with authentication and employees are frustrated by the current status reach out to one of our experts at ARES Consulting GmbH or contact [email protected] to make your application ready and secure with the future of authorization. We simplify authorization!