Secure Authentication with OAuth 2.0 and OpenID Connect for AWS resources
Streamlining Access and Identity Management in Modern Applications and AWS options to achieve them
Introduction
In today’s digital world, secure authentication is vital to protect users’ information and ensure seamless access to various applications and services. Two popular protocols that facilitate this process are OAuth 2.0 and OpenID Connect. In this article, we will delve into these protocols, breaking down the concepts in plain English, and exploring how they work together to enhance security and user experience.
Understanding OAuth 2.0
OAuth 2.0 is an authorization framework that allows applications to access resources on behalf of users without exposing their credentials. To explain it simply, imagine you want to use a fitness-tracking app to sync data from your smartwatch. Instead of sharing your username and password with the app, OAuth 2.0 enables you to grant it limited access to your data, ensuring your credentials remain secure.
Google Cloud services use Identity and Access Management (IAM) for authentication. IAM offers granular control, by principal and by resource.
The web servers in those smart wearables use Google API Client Libraries or Google OAuth 2.0 endpoints to implement OAuth 2.0 authorization to access Google APIs.
Most of the smart wearables which contain fitness tracking applications, use Google Healthcare API. The documentation below will demonstrate how to authorize the user data.
The process involves three main actors:
- The resource owner (user)
- The client application (the app you want to use)
- The authorization server (a trusted service handling authentication)
Resource Owner Password Credentials Auth flow
OAuth 2.0 utilizes tokens for access control. When the client application requests access to a resource, it redirects the user to the authorization server, where the user grants or denies the requested permissions. Upon approval, the authorization server issues an access token to the client application, enabling it to access the requested resource. This is the simple process of the Resource Owner Password Credentials Auth flow.
The OAuth 2.0 specification defines four types of authorization flows, one of which is the Resource Owner Password Credentials flow.
Example Scenario: Authorization (Resource Owner Password Credentials)
The client used must be highly trusted as it handles user credentials directly. In most cases, the client must be a first-party application. The Postman tool is a good example to illustrate the resource owner’s password credential authorization flow.
OAuth 2.0 provides flexibility in terms of authorization flows, such as the authorization code flow, implicit flow, and client credentials flow. These flows cater to different scenarios, allowing developers to choose the one that best fits their application’s requirements. Additionally, OAuth 2.0 supports scopes, which define the specific permissions requested by the client application. Scopes ensure that users have granular control over what data they are authorizing the application to access.
Exploring OpenID Connect
While OAuth 2.0 handles authorization, OpenID Connect builds on top of it to provide authentication capabilities. Authentication verifies the user’s identity, ensuring they are who they claim to be.
OpenID Connect acts as an identity layer, allowing users to authenticate themselves using an existing identity provider (IdP) such as Google or Facebook.
OpenID Connect introduces an additional actor called the identity provider. When a user wants to authenticate with a client application, the application redirects the user to the chosen IdP. The user then logs in with their credentials, and the IdP validates their identity. After successful authentication, the IdP issues an ID token containing information about the user, such as their name or email address. This token is securely passed back to the client application, which can then use it to personalize the user experience or make authorization decisions.
OpenID Connect supports the following authentication flows, such as implicit flow, authentication flow, resource owner password grant, and client credential grant. The following sequence diagram demontrate one of the above.
OpenID Connect provides a standardized set of claims within the ID token, such as sub (subject), aud (audience), and exp (expiration time). These claims provide verifiable information about the user, ensuring the client application can trust the identity asserted by the IdP. Additionally, OpenID Connect supports optional features like UserInfo endpoint and Discovery document, which simplify integration with identity providers and enhance interoperability.
The Synergy between OAuth 2.0 and OpenID Connect
OAuth 2.0 and OpenID Connect work together synergistically to provide a robust and secure authentication system. By combining the two, developers can leverage the authorization capabilities of OAuth 2.0 while obtaining verified user identity from OpenID Connect.
To achieve this synergy, OpenID Connect introduces new endpoints and token types to the OAuth 2.0 framework. It extends the standard OAuth 2.0 authorization flow by adding the ID token as an additional response. The ID token contains essential user information, allowing the client application to establish the user’s identity with confidence.
One of the key advantages of using OAuth 2.0 and OpenID Connect together is the ability to implement single sign-on (SSO) across multiple applications.
Once a user has authenticated with an IdP, subsequent requests to other applications that support OpenID Connect can leverage the existing session. This eliminates the need for the user to log in multiple times, enhancing user convenience and streamlining the authentication process.
Furthermore, OAuth 2.0 and OpenID Connect enable developers to build secure and scalable identity and access management solutions. These protocols provide standardized mechanisms for handling authentication and authorization, reducing the complexity of implementation and promoting interoperability across various systems and platforms.
Integration options with AWS for Securing Resources
a. AWS Identity and Access Management (IAM): IAM is a service that enables secure control access to AWS resources. It supports OAuth 2.0 and OpenID Connect for identity federation, which allows users to authenticate and obtain specific permissions to access AWS resources.
b. Amazon Cognito: Amazon Cognito is a fully managed identity service that supports OAuth 2.0 and OpenID Connect. It provides scalable authentication and authorization for web and mobile applications. Cognito User Pools is a feature of Amazon Cognito that manages user identities.
c. AWS API Gateway: AWS API Gateway is a service that allows you to create, publish, and manage APIs. It supports OAuth 2.0 and OpenID Connect for securing APIs by integrating authorization and authentication mechanisms.
Use Case
Suppose you are developing a mobile app that requires access to AWS resources. You can use OpenID Connect (OIDC) to establish trust between an OIDC-compatible identity provider (IdP) and your AWS account. This way, you can avoid creating custom sign-in codes or managing your own user identities.
For instance, let’s say you are developing a mobile app that allows users to upload photos to an S3 bucket. You can use Amazon Cognito to authenticate users through an OIDC-compatible IdP such as Google, Facebook, or Amazon. Once authenticated, the user can upload photos to the S3 bucket without having to sign in again 2.
Conclusion
As we navigate the ever-evolving digital landscape, one thing is clear, security and user experience are the twin pillars on which our tech world stands. OAuth 2.0 and OpenID Connect, like the dynamic duo of digital guardians, come to our rescue. They form an unbreakable alliance, enabling controlled access to resources while keeping our user credentials safe from harm’s reach. Stay safe and take care :)
FAQs
- When we talk about API access or look at API testing tools like Postman, and SoapUI we always see authorization and not authentication. why is that?
Those APIs that we are trying to access are actually endpoints to a particular resource. So, it is more appropriate to use the word authorization instead of authentication. However, authentication is always the first step in this process.
