Authentication in web applications is usually evaluated from the context of human users. To protect users from account takeovers and data compromise, services on the internet enforce various types of authentications, from OTP-based to advanced multi-factor authentication using technologies like FIDO2/WebAuthN.
However, behind for every user related transaction, there’s a series of service-to-service communications that take place. When a user visits a service, front-end interface of that service calls multiple backend services to execute the task. They in turn, call more services to complete the execution leading to unique security challenges. Here, I explore why OAuth 2.0, originally defined in RFC 6749 is the best available option currently to protect these backend interactions, ensuring secure and efficient communication throughout the entire chain of interactions.
Human to Service to Service(s)
When a human initiates a request, such as visiting a shopping website, they are first prompted to authenticate themselves, typically by providing credentials. Once authenticated, website has several options for communicating this information to a backend service to complete the request. It can be done by capturing user’s credentials, verify them, create a session, and include the session information in subsequent communications with the backend. While this approach may work for simple integrations, web applications are generally more complex, especially with a microservices architecture. In a microservices architecture, there are more than one service involved and call(s) need to be made across many to complete the user request with more security challenges. Each service call must be authenticated and authorized, to verify that only the appropriate services have permissions to take actions on behalf of the user.
Basic and Static Token-based Authentication Challenges
For enforcing authentication and authorization for service-to-service calls, providers often rely on either basic or static token-based authentication. These methods come with security issues in modern microservices architectures that are complex.
Like human with a password, in basic authentication, services are provided with a unique username and password commonly known as service accounts. These credentials are included in a base64-encoded format of authorization header of each request, which is typically passed along to all subsequent calls. Compromising a single service in the chain could compromise the entire system. Without a well-defined permissions management model, basic auth usually grants all-or-nothing access, making it difficult to implement fine-grained access control.
Static token-based authentication, slightly different from basic auth, shares many of basic authentication’s drawbacks. These tokens typically have a long lifespan, increasing the security issues if they’re compromised. Like basic auth, static tokens often grant broad access without easy ways to limit scope. Query parameters are particularly vulnerable because they may be logged or stored in browser history. Tracing specific user actions can be difficult when all calls use the same static token.
In both cases, the credentials or tokens usually don’t expire. This means that if an attacker obtains these credentials, they maintain control until the credentials are rotated or the attack is identified through other monitoring techniques.
OAuth 2.0
OAuth 2.0 offers a robust framework for secure and efficient communication. It addresses the security issues discussed earlier. When explaining modern authentication architectures, sometimes OAuth 2.0 is interchangeably used along with OpenID Connect (OIDC), but there is a key difference between the two, while OAuth 2.0 focuses on authorization, OIDC is built on top of it to handle authentication.
In an OAuth 2.0 enforced architecture, credential transfer and validation only happen between the client (user or service) and the authorization server and responsible for verifying credentials. Authorization server is also the one who produces credentials. It then issues tokens which are passed as part of subsequent calls, this limits credential exposure to just two parties. These tokens are time bound and can be set to as low few seconds depending on the sensitivity of data involved, further mitigating the issues of token compromises even if one occurs.
OAuth grants
OAuth 2.0 supports several grant types but only three are recommended: (1) Authorization Code with PKCE, (2) Client Credentials and (3) Device Grant. Authorization code grant is used when there is a human interaction is involved, such as user trying to purchase an item and that requires logging into the application. Client Credentials grant is used when there is no human interaction is required, such as one backend API is calling another backend API, for example to complete the payment request and fill purchase request made by the user. Device grant on the other hand is used when there is a human interaction with input constrained devices are involved such as TVs. In all these grants, it is authorization server’s responsibility for validating credentials and issuing tokens without ever having to expose credentials. Users, humans or services in this context will only have to disclose their credentials to authorization server. The other grants are not recommended due to various reasons, and I recommend reading resources provided in below section for more details.
Conclusion
OAuth 2.0 is a well-defined and widely used framework for securing service-to-service calls. Along with mitigating the issues of basic and static token-based authentications, it also provides flexibility with credentials management. OAuth 2.0 when properly deployed will increase controls of user privacy and can be utilized as a building block for complying with laws where data protection is a key concern such as financial services. The industry wide adoption of OAuth 2.0 also allows for easier integration with third-party APIs. If you are a developer or security practitioner for an organization where basic or static token-based authentications are still a norm, take a closer look to familiarize with OAuth 2.0 and its security benefits. It is indeed a fundamental shift which can bring new challenges in terms of additional steps for token generation and validation which could impact response speeds, but with proper planning, API security can be significantly improved without impact to availability.
For organizations planning to embark on this journey, consider starting with providing necessary training and resources to help your development teams. Like other secure software best practices, controls should be established for regularly review and update OAuth 2.0 implementation to address new vulnerabilities and incorporate emerging best practices. Along with https://oauth.net/, Which OAuth 2.0 Flow Should I Use from Auth0 and OAuth 2.0 tutorial could be considered good resources to get started.
Opinions expressed in this article are solely the Author’s own and do not express the views or opinions of the Author’s employer.
