Essential Moments in the OAuth and OpenID Connect Timeline

Like all technological achievements, individuals' cumulative efforts and contributions lead to something great. The
current state of application security results from many talented individuals who take security seriously, coming
together to build a technology from which we all benefit. Without them, we’d likely all be building bespoke security
solutions with varying levels of vulnerability and interoperability. Thank goodness for standards!

In this post, we take a trip down memory lane and explore some of the standards created over the last 15 years, both in
the IETF and the OpenID Foundation, that make OAuth and OpenID Connect what they are today.

The OAuth 2.0 and OpenID Connect Timeline

While Internet Engineering Task Force (IETF) and OpenID working groups created many standards, we picked a few that have
significantly impacted security implementations in application development, specifically around OAuth and OpenID
Connect.

OAuth 2.0 - April 2010 - October 2012 (RFC 6749)

In early 2010, contributors from Microsoft, Yahoo!, and Google proposed a specification called OAuth Web Resource
Authorization Profiles (OAuth WRAP) to
replace OAuth 1.0, which developers found too hard to use because of its
requirement to canonicalize HTTP messages. It used bearer tokens, rather than proof-of-possession tokens - another
simplification over OAuth 1.0. It was contributed to the IETF OAuth working group, and
became OAuth 2.0 in October 2012. The OAuth 2.0 Authorization Framework
enables third-party applications to obtain limited access to resources at an HTTP endpoint. The specification enables
resource owners to approve interactions between themselves, the third-party application, and the protected resource.

You've seen the consent screen when you’ve logged into services authenticated using a social login. For developers,
tooling for services like GitHub or GitLab uses OAuth to access secured elements such as repositories, issue trackers,
and other resources.

OpenID Connect - March 2010 - February 2014

The OpenID Connect standard is the most widely used login protocol today. It spans use cases from mobile to Web to
enterprise to cloud, and can be deployed at high security levels. It’s the protocol everyone uses every day without
knowing it, because it’s plumbing - not a consumer brand.

As you can see from the timelines, it was built along side of OAuth 2.0, JWT, JWS, JWE, JWK, JWA and other protocols and
data formats - all informing one another during standards development. It’s hard to imagine an online security world
without OpenID Connect!

JSON Web Token (JWT) - October 2010 - May 2015 (RFC 7519)

It’s hard to envision a time in web-based security when JSON Web Tokens (JWTs) weren’t present, but that time did exist.
The JSON Web Token is almost synonymous with modern security practices, and imagine it turned 10 years old in May
2025. Development of the JWT, JWS, JWE, JWK, and JWA specs began in October 2010.
The format allows parties to provide secure JSON payloads that are encoded and signed using a JSON Web Signature (JWS)
and/or encrypted using JSON Web Encryption (JWE). It offers a simple yet straightforward secured claims representation
that has helped make security interoperability a reality.

“We designed JWT to be a simple, general JSON-based token format. Of course, we kept our identity use cases in mind -
particularly ID Tokens. Little did we know at the time that JWTs would end up being used for all kinds of other things.
For instance, I learned in 2020
that JWTs are helping combat fraudulent and unwanted telephone calls by securing
Caller ID information. One sign of a successful standard is that it is used for things that the inventors never
envisioned!”
-- Mike Jones, author of several widely-used OpenID, OAuth, JOSE, COSE, ACE, and
SecEvent specs

OpenID Certification Program - July 2014 - April 2015

The OpenID Foundation started developing a certification program for OpenID Connect implementations starting in July
2014, soon after the specification was completed in February 2014,
and launched the certification program in April 2015.
Certification is critical both for interoperability and security. Certification improves interoperability by ensuring
that certified implementations faithfully follow the specification. And Certification improves security by ensuring that
implementations correctly implement the features needed to secure deployments.

The certification program has since expanded to cover FAPI 1.0, FAPI 2.0, and several other groups of OpenID
specifications.

Proof Key for Code Exchange or PKCE - July 2013 - September 2015 (RFC 7636)

As OAuth gained popularity, it has unfortunately attracted the attention of malicious actors. In July 2013, Nat Sakimura
and several other authors proposed Proof Key for Code Exchange (PKCE) to protect against authorization code interception
attacks. In short, if an attacker obtains the authorization code, they can use it to generate an access token.

PKCE solves this problem by introducing a cryptographically generated random key. We’ll let the authors explain.

To mitigate this attack, this extension utilizes a dynamically created cryptographically random key called "code
verifier". A unique code verifier is created for every authorization request, and its transformed value, called "code
challenge", is sent to the authorization server to obtain the authorization code. The authorization code obtained is
then sent to the token endpoint with the "code verifier", and the server compares it with the previously received
request code so that it can perform the proof of possession of the "code verifier" by the client. This works as the
mitigation since the attacker would not know this one-time key since it is sent over TLS and cannot be intercepted.
– RFC 7636

In short, even if an attacker were to intercept the authorization code, they would not be able to redeem it for an
access token because they would not have the original secret.

OAuth 2.0 Authorization Server Metadata - November 2015 - June 2018 (RFC 8414)

The ability to publish authorization server metadata significantly increased the ease of interoperability among OAuth
components produced by different parties. Rather than having to obtain AS configuration information, such as endpoint
URLs, from developer documentation, it can be obtained programmatically from the published metadata. This is less
error-prone and more convenient.

Mutual-TLS Client Authentication and Certificate-Bound Access Tokens - October 2016 - February 2020 (RFC 8705)

Some organizations value the security and peace of mind that certificates provide. While certificates are not as easy to
manage as string-based secrets, the infrastructure surrounding them makes it very difficult to replicate a fraudulent
version.

In October 2016, several authors introduced the concept of certificate-bound access and refresh tokens using mutual
Transport Layer Security authentication with X.509 certificates. Using certificates enforces the trusted relationship
between client and server, as the authorization server only issues tokens to the certificate-owning client.

Resource Indicators for OAuth 2.0 - March 2016 - February 2020 (RFC 8707)

As OAuth developers' needs evolve, so do specifications. In March 2016, an enhancement to OAuth 2.0 was proposed to
allow clients to specify the resource server where an issued access token will be utilized. This additional information
allows the authorization server to make more informed decisions about which policies to apply, which can lead to changes
to the token and its contents.

While a seemingly minor change to the specification, this change gives those implementing authorization servers more
options to deliver secure solutions to a growing number of consumers.

JWT-Secured Authorization Request (JAR) - February 2014 - August 2021 (RFC 9101)

The final OpenID Connect Core specification standardized signed Request Objects in February 2014. Before that,
information passed in an authorization request was in parameters encoded in the URI. As you can imagine, this had limits
and security implications, as URIs have size limitations, and auditing systems can accidentally log sensitive
information that attackers can exfiltrate. RFC 9101 copied the signed Request Object definition from OpenID Connect Core
into an OAuth specification, making signed requests also available when not using OpenID Connect.

This specification sends request parameters by value in JWT format in the HTTP request body or by reference using a URL
referencing the JWT containing the request parameters. These JWTs can be signed and optionally encrypted, and they are
not subject to size limits when passed by reference.

While some older implementations still exist, many authorization servers have adopted the JWT-secured authorization
request due to its advantages.

Pushed Authorization Requests or PAR - September 2019 - September 2021 (RFC 9126)

Until this RFC was proposed, communication between authorization servers and clients always occurred through stateless
communication via a user agent, such as a browser. While this is still secure, there are limitations.

This Pushed Authorization Requests (PAR) RFC created a mechanism for a client to push request information to an
authorization server using a backchannel mechanism. This requires the server to maintain the state of the pending
requests.

PAR allows the authorization server to authenticate the client before any user interaction happens. The increased
confidence in the identity of the client during the authorization process allows the authorization server to refuse
illegitimate requests much earlier in the process, which can prevent attempts to spoof clients or otherwise tamper with
or misuse an authorization request.

For ASP.NET Core Developers, our very own Joe DeCock implemented the .NET implementation of PAR.

Demonstrating Proof of Possession (DPoP) - March 2019 - September 2023 (RFC 9449)

Replay attacks are a common vector for attackers. If an attacker can access a valid token, they can impersonate the
original caller. Demonstrating Proof of Possession (DPoP) defines a proof-of-possession mechanism that protects all
involved parties from replay attacks targeting access tokens and, in some cases, refresh tokens.

Demonstrating Proof of Possession (DPoP) is an application-level mechanism for sender-constraining OAuth [RFC6749]
access and refresh tokens. It enables a client to prove the possession of a public/private key pair by including a DPoP
header in an HTTP request. The value of the header is a JSON Web Token (JWT) [RFC7519] that enables the authorization
server to bind issued tokens to the public part of a client's key pair. Recipients of such tokens are then able to
verify the binding of the token to the key pair that the client has demonstrated that it holds via the DPoP header,
thereby providing some assurance that the client presenting the token also possesses the private key. In other words,
the legitimate presenter of the token is constrained to be the sender that holds and proves possession of the private
part of the key pair.

By binding tokens to cryptographic keys, whose private keys are not disclosed by the protocol, attackers cannot use any
intercepted tokens, because they do not possess the private keys securing them. The client always retains a private key
that is never transmitted to the server, although proof of its possession is sent in the form of a signature. This gives
us a higher-security option than the bearer tokens that were previously always used with OAuth 2.0. Private and public
key pairs are great [RFC 6750].

FAPI 2.0 - March 2021 - February 2025

FAPI 2.0 is a security profile covering several standards that organizations should adopt to develop a security posture
appropriate to protecting high-value resources. These resources are typically found in financial services, e-health and
e-government, but are not limited to those fields. If you work with sensitive data or want additional security, FAPI 2.0
is something you should explore. The FAPI 2.0 approach comes with extra overhead and maintenance costs that may be
inappropriate for some security implementations. FAPI 2.0 became final in February 2025. It builds on the lessons
learned building and deploying FAPI 1.0, which was completed in March 2021. (FAPI used to stand for Financial-grade
API, but for 2.0, it became simply “FAPI”, no longer being an acronym.)

Read more about the FAPI 2.0 Security Profile if you’re
interested in implementing it as your security profile. Duende IdentityServer already supports all these features, so
Duende customers only need to take a few steps to enable it in their instances.

Conclusion

The IETF's and the OIDF’s hard work has improved the security world, with OAuth and OpenID Connect underpinning much of
modern development's security. As Duende employees attend these meetings, we thought back at all the meaningful
conversations we engaged in and figured we would choose some of our favorite and most impactful specifications over the
last 15 years, but we’d love to hear about yours.

If you have a favorite OpenID standard or RFC, and let’s face it, who doesn’t? Please let us know in the comments. As
always, we’ll watch for the latest coming from the OIDF and IETF and actively participate in the working groups to bring
the latest and greatest security practices to .NET.