F5 APM and OAuth (Open Authorization): The Future of User and Application Authentication and Authorization
As we move more and more towards API (application programming interface) communication between applications, the need to find a way to authenticate and authorize users using web browsers and applications is becoming more pressing.
SAML(Security Assertion Markup Language) Basics:
Historically, user authentication within corporate environments primarily relied on protocols such as LDAP, Kerberos, Radius, and TACACS. These methods were effective for internal users either located at company premises or connecting through VPN. However, with the advent of cloud-based applications like Salesforce and Office 365, there arose a need for a unified authentication system to securely manage access to these applications for legitimate users. The challenge was integrating diverse authentication methods into a single, centralized Identity and Access Management (IAM) system. This integration was crucial for both on-premises and cloud-based IAM systems. SAML emerged as a solution to this challenge. It enables cloud applications, referred to as SAML Service Providers (SP), to connect with Authentication servers, known as SAML Identity Providers (IDP). SAML utilizes XML for data exchange and the Internet for transport, ensuring secure communication between cloud applications and IAM systems.
For further information on SAML, I suggest reading the link below before moving onto the section below: https://my.f5.com/manage/s/article/K08200035
OAuth Basics:
While SAML is effective for certain scenarios, it lacks capabilities for handling application-to-application communication via APIs. This is where OAuth comes into play!
OAuth is a more recent and complex protocol than SAML and it does not use XML for a data format. It is versatile in authenticating users through web browsers using authorization codes, similar to SAML. Additionally, OAuth can authenticate and authorize web applications, employing Access Tokens in two formats: JWT (JSON Web Token) and Opaque, which will be discussed later.
Although OAuth can substitute for SAML, the question arises: why replace a functioning system? The rationale is to streamline authentication by using a consistent method for both users and applications. OAuth’s Authorization Grant option mirrors SAML in a way: users are redirected from the application to the Authorization Server (analogous to SAML’s IDP), receive a grant after authentication, and return to the application for access. Beyond this, OAuth offers greater flexibility. It enables users to submit credentials directly to the application, which can then exchange these credentials for a token. This level of flexibility, distinguishing OAuth from SAML, is facilitated by OAuth's design incorporating client and resource server objects, not just the SAML SP concept.
Client: Application requesting access to a protected resource on behalf of the Resource Owner.
Resource Server: Server hosting the protected resources. This separation allows much more flexibility than SAML.
Fun Fact: If you ever logged into application that asks you to register or use your google or facebook credentials, then you have already used OAuth, as this is application to application communication that is done with OAuth!
High Level Diagram of OAUTH with Grant Type Authorization
The issue is modifying applications to support OAuth can be quite complex. This is where using F5 APM as a central system offers significant advantages F5 APM is versatile and can function in various roles within the OAuth framework. It can act as the client, resource server (RS), authorization server, or even simultaneously as both client and RS. In its role as a client, F5 APM is responsible for obtaining the authorization grant from the user and exchanging it for an access token. Subsequently, as a resource server, it uses this access token to retrieve user information and evaluate user permissions based on user claims, akin to SAML attributes. This process enables F5 APM to decide whether to allow or block user access.
To summarize, the client role in this context is focused on authentication, primarily acquiring the access token. The resource server's role involves retrieving user data based on the access token and authorizing the user or application. This dual functionality of F5 APM simplifies the implementation of OAuth, providing a seamless and efficient solution for user authentication and authorization.
OAuth Opaque and JWT Tokens:
Access tokens can be opaque, essentially random strings that contain no user information. In such cases, the Resource Server (RS) must contact the Authorization Server (AS) to retrieve the useful data, such as the Active Directory (AD) groups that the user or application belongs to. The AS needs to stores these opaque tokens in its database, and they may be accompanied by a refresh token that can be used to request a new access token upon expiration. For example, opaque tokens are used by Google, when it acts as an OAuth AS.
Due to the lack of user information in opaque tokens, OpenID Connect was developed as an extension to OAuth. It allows the RS, upon receiving an opaque access token, to send a request to the OpenID Connect Endpoint on the AS server to retrieve user data in the form of claims and scopes in a JWT ID Token. First the RS must send the request with the correct scope, guiding the AS on which claims to return in the ID JWT token. For secure communication, RS and OAuth clients can use secrets that are shared between them and the AS server or they can exchange SSL certificates (like SAML).
Alternatively, access tokens can be in JWT format, as seen with Azure AD, where the token itself contains necessary user information like AD group memberships and email addresses. In this scenario, the RS does not need to directly contact the AS to verify the JWT, as it is signed with SSL certificates, ensuring its authenticity. Additionally, JWTs can be encrypted to prevent end users from viewing their contents, akin to encrypting SAML assertions. It's also important to regularly verify if the SSL certificates used for signing the JWT have been updated.
It is even possible for the Access token to be in a JWT format, rather than an opaque format like with Azure AD, where the access token contains all of the necessary information in the form of claims like user AD groups and email address. For the RS to verify the JWT token, it does not need to directly contact the AS server as the JWT will be signed with SSL certificates, so the RS will know that the JWT is correct. The JWT can be encrypted, so that the end users cannot see the JWT data, like encrypting SAML assertions. It’s also important to regularly verify if the SSL certificates that are used to sign the JWT token are changed.
Note: Starting from version 17.0, F5 APM now supports JWT encryption!
Opaque Token example:
68bee27f2978728636b7a680063216b40df3c0fc2ce0773ca1ef677e8c4e2169
JWT token (ID/Access) example
Exploring F5 APM & Oauth Capabilities:
F5 APM as an Authorization Server (AS): As I mentioned the F5 APM can serve as the AS, validating user credentials with the local Active Directory and issuing either opaque or JWT tokens. F5 supports both token types. For a great example, see the “Implementing Basic Oauth with F5 BIG-IP APM” article on F5 Devcentral here.
F5 APM as Both Client and Resource Server (RS): F5 APM can function as both the client application and RS at the same time, particularly when using OAuth instead of SAML for web users. For more detail on the configuration instructions, please see this F5 knowledge article “Configuring an OAuth setup using one BIG-IP APM system as an OAuth authorization server and another as the OAuth client" here.
F5 as an OAuth Client: In scenarios where another F5 APM device acts as the RS, closer to the resource servers, F5 APM can exclusively be the client. An excellent example of this setup is detailed in "Configuring BIG-IP APM as OAuth client with Google OAuth authorization server”, found here.
Note: Google has a free service that can be used as an AS server.
F5 APM as a Resource Server: F5 APM can also act solely as the RS for use cases where a third-party application is the real client and it tries to access resources that the F5 APM protects by providing the access token through the API communication. See here for a good example.
F5 as an RS server for API communication and Azure AD as OAUTH AS server
For JWT implementations with Azure AD, F5 by default knows where to connect and download the latest Azure SSL certificates that are used to sign in the JWT tokens, making things much easier.
F5 APM GUI with Predefined Azure AD Parameters for JWT Token Certificate Checks
Click here for a great resource that gives an overview of F5's applications in OAuth scenarios: "K42333110: Overview of OAuth 2.0 Use Cases with BIG-IP APM."
F5 APM OAuth examples:
The below configuration is where F5 APM is acting as the OAuth Client and OAuth RS and the Google API is the free OAuth AS server. The Google API returns a claim named "ad", which is saved to a session variable that can be used in the VPE (Visual Policy Editor) to allow only "admin" users. The Google API is free - anyone can request a 30-day trial from F5 and test with the Google API or the trial version of Azure AD/Cloud.
F5 APM VPE (Virtual Policy Editor)
F5 APM has guided configurations which make it easier to configure F5 APM as an OAuth Client, OAuth RS or OAuth Server that can provide opaque and JWT tokens. A single trial F5 APM device can also be configured to perform all three roles in OAuth testing. To do this, set the device to function as both the Authorization Server (AS) and the Client/Resource Server (RS), ensuring that each role listens to distinct Virtual Server IP addresses on the F5 device.
F5 APM Guided Configuration Wizards
F5 APM also has an API Protection feature that leverages OAuth for API traffic on a per-request basis. This is particularly useful since APIs often don't support sessions, JavaScript, and cookies. There's a great informative video on this feature: https://www.youtube.com/watch?v=-2ndGH9Dp1Q
In Summary:
OAuth will become more and more popular as the time goes on for it's flexibility to handle both web users and/or API traffic. It is much better to use a device like F5 APM to do the OAuth communication as it eliminates the need for modifications in the end application. F5 APM offers Single Sign-On (SSO) capabilities, allowing for the transmission of data to backend applications via HTTP headers or, in the case of JWT, by simply forwarding the JWT token or generating a new one. As an OAuth Authorization Server, F5 APM efficiently handles both JWT and opaque tokens at the same time, which is really convenient. Additionally, F5 APM can even translate the authentication between OAuth at the frontend and for example, Kerberos at the backend.
Author: Nikolay Dimitrov