Mike Jones: self-issued

Musings on Digital Identity

Category: OAuth Page 2 of 11

Working Group Adoption of the JWK Thumbprint URI Specification

By

On January 29, 2022

In Cryptography, IETF, OAuth, OpenID, Specifications

OAuth logoThe IETF OAuth working group has adopted the JWK Thumbprint URI specification. The abstract of the specification is:

This specification registers a kind of URI that represents a JSON Web Key (JWK) Thumbprint value. JWK Thumbprints are defined in RFC 7638. This enables JWK Thumbprints to be used, for instance, as key identifiers in contexts requiring URIs.

The need for this arose during specification work in the OpenID Connect working group. In particular, JWK Thumbprint URIs are used as key identifiers that can be syntactically distinguished from other kinds of identifiers also expressed as URIs in the Self-Issued OpenID Provider v2 specification.

Given that the specification does only one simple thing in a straightforward manner, we believe that it is ready for working group last call.

The specification is available at:

Described more of the motivations for the JWK Thumbprint URI specification

By

On January 12, 2022

In Cryptography, IETF, OAuth, OpenID, Specifications

OAuth logoAs requested by the chairs during today’s OAuth Virtual Office Hours call, Kristina Yasuda and I have updated the JWK Thumbprint URI specification to enhance the description of the motivations for the specification. In particular, it now describes using JWK Thumbprint URIs as key identifiers that can be syntactically distinguished from other kinds of identifiers also expressed as URIs. It is used this way in the Self-Issued OpenID Provider v2 specification, for instance. No normative changes were made.

As discussed on the call, we are requesting that that the chairs use this new draft as the basis for a call for working group adoption.

The specification is available at:

JWK Thumbprint URI Specification

By

On November 24, 2021

In Cryptography, IETF, OAuth, OpenID, Specifications

IETF logoThe JSON Web Key (JWK) Thumbprint specification [RFC 7638] defines a method for computing a hash value over a JSON Web Key (JWK) [RFC 7517] and encoding that hash in a URL-safe manner. Kristina Yasuda and I have just created the JWK Thumbprint URI specification, which defines how to represent JWK Thumbprints as URIs. This enables JWK Thumbprints to be communicated in contexts requiring URIs, including in specific JSON Web Token (JWT) [RFC 7519] claims.

Use cases for this specification were developed in the OpenID Connect Working Group of the OpenID Foundation. Specifically, its use is planned in future versions of the Self-Issued OpenID Provider v2 specification.

The specification is available at:

Server-contributed nonces added to OAuth DPoP

By

On October 6, 2021

In IETF, OAuth, Specifications

OAuth logoThe latest version of the “OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP)” specification adds an option for servers to supply a nonce value to be included in the DPoP proof. Both authorization servers and resource servers can provide nonce values to clients.

As described in the updated Security Considerations, the nonce prevents a malicious party in control of the client (who might be a legitimate end-user) from pre-generating DPoP proofs to be used in the future and exfiltrating them to a machine without the DPoP private key. When server-provided nonces are used, actual possession of the proof-of-possession key is being demonstrated — not just possession of a DPoP proof.

The specification is available at:

OAuth 2.0 JWT-Secured Authorization Request (JAR) is now RFC 9101

By

On August 21, 2021

In Claims, IETF, JSON, OAuth, OpenID, Specifications

IETF logoThe OAuth 2.0 JWT-Secured Authorization Request (JAR) specification has been published as RFC 9101. Among other applications, this specification is used by the OpenID Financial-grade API (FAPI). This is another in the series of RFCs bringing OpenID Connect-defined functionality to OAuth 2.0. Previous such RFCs included “OAuth 2.0 Dynamic Client Registration Protocol” [RFC 7591] and “OAuth 2.0 Authorization Server Metadata” [RFC 8414].

The abstract of the RFC is:


The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that authorization request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that a) the communication through the user agents is not integrity protected and thus, the parameters can be tainted, b) the source of the communication is not authenticated, and c) the communication through the user agents can be monitored. Because of these weaknesses, several attacks to the protocol have now been put forward.


This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication, and confidentiality properties of the authorization request are attained. The request can be sent by value or by reference.

Thanks to Nat Sakimura and John Bradley for persisting in finishing this RFC!

OAuth 2.0 JWT Secured Authorization Request (JAR) sent back to the RFC Editor

By

On April 21, 2021

In Claims, IETF, JSON, OAuth, OpenID, Specifications

OAuth logoAs described in my last post about OAuth JAR, after it was first sent to the RFC Editor, the IESG requested an additional round of IETF feedback. I’m happy to report that, having addressed this feedback, the spec has now been sent back to the RFC Editor.

As a reminder, this specification takes the JWT Request Object from Section 6 of OpenID Connect Core (Passing Request Parameters as JWTs) and makes this functionality available for pure OAuth 2.0 applications — and does so without introducing breaking changes. This is one of a series of specifications bringing functionality originally developed for OpenID Connect to the OAuth 2.0 ecosystem. Other such specifications included OAuth 2.0 Dynamic Client Registration Protocol [RFC 7591] and OAuth 2.0 Authorization Server Metadata [RFC 8414].

The specification is available at:

An HTML-formatted version is also available at:

OAuth 2.0 JWT Secured Authorization Request (JAR) updates addressing remaining review comments

By

On March 19, 2021

In Claims, IETF, JSON, OAuth, OpenID, Specifications

OAuth logoAfter the OAuth 2.0 JWT Secured Authorization Request (JAR) specification was sent to the RFC Editor, the IESG requested an additional round of IETF feedback. We’ve published an updated draft addressing the remaining review comments, specifically, SecDir comments from Watson Ladd. The only normative change made since the 28 was to change the MIME Type from “oauth.authz.req+jwt” to “oauth-authz-req+jwt“, per advice from the designated experts.

As a reminder, this specification takes the JWT Request Object from Section 6 of OpenID Connect Core (Passing Request Parameters as JWTs) and makes this functionality available for pure OAuth 2.0 applications — and does so without introducing breaking changes. This is one of a series of specifications bringing functionality originally developed for OpenID Connect to the OAuth 2.0 ecosystem. Other such specifications included OAuth 2.0 Dynamic Client Registration Protocol [RFC 7591] and OAuth 2.0 Authorization Server Metadata [RFC 8414].

The specification is available at:

An HTML-formatted version is also available at:

OAuth 2.0 JWT Secured Authorization Request (JAR) sent to the RFC Editor

By

On August 20, 2020

In Claims, IETF, JSON, OAuth, OpenID, Specifications

OAuth logoCongratulations to Nat Sakimura and John Bradley for progressing the OAuth 2.0 JWT Secured Authorization Request (JAR) specification from the working group through the IESG to the RFC Editor. This specification takes the JWT Request Object from Section 6 of OpenID Connect Core (Passing Request Parameters as JWTs) and makes this functionality available for pure OAuth 2.0 applications — and intentionally does so without introducing breaking changes.

This is one of a series of specifications bringing functionality originally developed for OpenID Connect to the OAuth 2.0 ecosystem. Other such specifications included OAuth 2.0 Dynamic Client Registration Protocol [RFC 7591] and OAuth 2.0 Authorization Server Metadata [RFC 8414].

The specification is available at:

An HTML-formatted version is also available at:

Again, congratulations to Nat and John and the OAuth Working Group for this achievement!

Refinements to “OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP)”

By

On May 4, 2020

In IETF, OAuth, Specifications

OAuth logoA number of refinements have been applied to the DPoP specification. As recorded in the History entries, they are:

  • Editorial updates
  • Attempt to more formally define the DPoP Authorization header scheme
  • Define the 401/WWW-Authenticate challenge
  • Added invalid_dpop_proof error code for DPoP errors in token request
  • Fixed up and added to the IANA section
  • Added dpop_signing_alg_values_supported authorization server metadata
  • Moved the Acknowledgements into an Appendix and added a bunch of names (best effort)

Thanks to Brian Campbell for doing the editing for this round.

The specification is available at:

Working group adoption of “OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP)”

By

On April 6, 2020

In IETF, OAuth, Specifications

OAuth logoWe’re making progress on a simple application-level proof-of-possession solution for OAuth 2.0. I’m pleased to report that DPoP has now been adopted as an OAuth working group specification. The abstract of the specification is:

This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens.

The specification is available at:

OAuth 2.0 DPoP for the Implicit Flow

By

On March 9, 2020

In IETF, OAuth, Specifications

OAuth logoAs I previously described, members of the OAuth working group have developed a simplified approach to providing application-level proof-of-possession protections for OAuth 2.0 access tokens and refresh tokens. This approach is called OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP). Among other benefits, this approach does not require a complicated and error-prone procedure for signing HTTP requests, as some past approaches have.

However, the DPoP specification to date has assumed that the client is using the OAuth authorization code flow. As promised at the last IETF meeting, we’ve now published a simple companion specification that describes how DPoP can be used with the OAuth implicit flow — in which access tokens are returned directly from the authorization endpoint. The specification is mercifully brief because very little had to be added to supplement the existing DPoP spec to enable use of DPoP with the implicit flow. Thanks to Brian Campbell and John Bradley for whiteboarding this solution with me.

Finally, in a related development, it was decided during the OAuth virtual interim meeting today to call for working group adoption of the core DPoP draft. That’s an important step on the journey towards making it a standard.

The specification is available at:

An HTML-formatted version is also available at:

Two New OAuth RFCs: MTLS (RFC 8705) and Resource Indicators (RFC 8707)

By

On March 3, 2020

In Cryptography, IETF, OAuth, OpenID, Specifications

OAuth logoTwo widely used OAuth specifications have recently become RFCs. Here’s a bit about both specs.

RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens

Abstract: This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client’s mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token.

Client certificates are widely used in the financial industry to authenticate OAuth clients. Indeed, this specification was developed in part because it was needed by the OpenID Financial-Grade API (FAPI) specifications. It is in production use by numerous Open Banking deployments today.

RFC 8707: Resource Indicators for OAuth 2.0

Abstract: This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access.

This specification standardizes the “resource” request parameter that is used by Azure Active Directory (AAD) V1 to specify the target resource for an OAuth authorization request.

JSON Web Token Best Current Practices is now RFC 8725 and BCP 225

By

On February 19, 2020

In Claims, Cryptography, IETF, JSON, OAuth, Specifications

OAuth logoThe JSON Web Token Best Current Practices specification is now RFC 8725 and BCP 225. The abstract of the specification is:

JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs.

The JSON Web Token (JWT) specification [RFC 7519] was approved in May 2015, almost five years ago, and has been in production use since at least 2013. This Best Current Practices specification contains a compendium of lessons learned from real JWT deployments and implementations over that period. It describes pitfalls and how to avoid them as well as new recommended practices that enable proactively avoiding problems that could otherwise arise. Importantly, the BCP introduces no breaking changes to the JWT specification and does not require changes to existing deployments.

The BCP came about as JWTs were starting to be used in new families of protocols and applications, both in the IETF and by others. For instance, JWTs are being used by the IETF STIR working group to enable verification of the calling party’s authorization to use a particular telephone number for an incoming call, providing verified Caller ID to help combat fraudulent and unwanted telephone calls. The advice in the BCP can be used by new JWT profiles and applications to take advantage of what’s been learned since we created the JSON Web Token (JWT) specification over a half decade ago.

JWTs helping combat fraudulent and unwanted telephone calls

By

On February 12, 2020

In Claims, IETF, OAuth, Safety, Specifications

IETF logoI wanted to bring two excellent articles by the IETF on work by the STIR working group to combat fraudulent and unwanted telephone calls to your attention:

Abstract: Providers of voice over IP in the United States will be required to implement the IETF’s Secure Telephony Identity Revisited (STIR) protocol as a result of recently enacted legislation to address some of the root causes of illegal robocalling on the telephone network.

Abstract: Recently, the output of the IETF Secure Telephony Identity Revisited (STIR) working group has received considerable attention from service providers, regulators, and the press because it addresses some of the root causes of the illegal robocalling which has crippled the telephone network.

I love this work for two reasons. First, like the rest of you, I receive a huge volume of unwanted and often fraudulent phone calls. I love that engineers and regulators are partnering to take concrete steps to reduce the volume of these illegal and annoying calls.

Second, I love it that the STIR protocols are using JSON Web Tokens (JWTs) under the covers as the format to represent verifiable statements about legitimate uses of telephone numbers, enabling verifiable Caller ID. It’s often said that one sign of a standard having succeeded is that it’s used for things that the inventors never imagined. This is certainly such a case! I’m proud that the JSON Web Token, which we originally designed with digital identity use cases in mind, is now being used in a completely different context to solve a real problem experienced by people every day.

OAuth 2.0 Token Exchange is now RFC 8693

By

On January 15, 2020

In IETF, OAuth, Specifications

OAuth logoThe OAuth 2.0 Token Exchange specification is now RFC 8693. The abstract of the specification is:

This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation.

This specification standardizes an already widely-deployed pattern in production use by Box, Microsoft, RedHat, Salesforce, and many others. Thanks to all of you who helped make a standard for this important functionality!

JSON Web Token Best Current Practices sent to the RFC Editor

By

On October 22, 2019

In Claims, Cryptography, IETF, JSON, OAuth, Specifications

OAuth logoI’m pleased to report that the JSON Web Token (JWT) Best Current Practices (BCP) specification is now technically stable and will shortly be an RFC — an Internet standard. Specifically, it has now progressed to the RFC Editor queue, meaning that the only remaining step before finalization is editorial due diligence. Thus, implementations can now utilize the draft specification with confidence that that breaking changes will not occur as it is finalized.

The abstract of the specification is:

JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity, and in other application areas. The goal of this Best Current Practices document is to provide actionable guidance leading to secure implementation and deployment of JWTs.

Thanks to the OAuth working group for completing this important specification.

The specification is available at:

An HTML-formatted version is also available at:

OAuth Device Flow is now RFC 8628

By

On August 16, 2019

In IETF, OAuth, Specifications

OAuth logoThe OAuth Device Flow specification (recently renamed to be the OAuth 2.0 Device Authorization Grant specification) is now RFC 8628. The abstract describes the specification as:

The OAuth 2.0 device authorization grant is designed for Internet-connected devices that either lack a browser to perform a user-agent-based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources by using a user agent on a separate device.

This specification standardizes an already widely-deployed pattern in production use by Facebook, ForgeRock, Google, Microsoft, Salesforce, and many others. Thanks to all of you who helped make this existing practice an actual standard!

OAuth 2.0 Token Exchange specification sent to the RFC Editor

By

On July 24, 2019

In Claims, IETF, JSON, OAuth, Specifications

OAuth logoI’m very pleased to report that the OAuth 2.0 Token Exchange specification is now technically stable and will shortly be an RFC — an Internet standard. Specifically, it has now progressed to the RFC Editor queue, meaning that the only remaining step before finalization is editorial due diligence. Thus, implementations can now utilize the draft specification with confidence that that breaking changes will not occur as it is finalized.

The abstract of the specification is:

This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation.

Thanks to the OAuth working group for completing this important specification. And thanks to Brian Campbell for taking point in making the recent updates to get us here.

The specification is available at:

An HTML-formatted version is also available at:

OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer

By

On April 3, 2019

In IETF, OAuth, Specifications

OAuth logoI’m excited that a new, simpler approach for application-level proof of possession of OAuth access tokens and refresh tokens is being developed by members of the IETF OAuth working group. The effort is led by Daniel Fett, who had previously done formal analysis of the OAuth protocol. I wanted to bring it to your attention now to solicit your early feedback. This approach was designed in discussions at the Fourth OAuth Security Workshop and is captured in a new individual draft specification for Demonstration of Proof-of-Possession (DPoP) intended for the OAuth working group. The abstract of the new specification is:

This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows to detect replay attacks with access and refresh tokens.

The specification is still an early draft and undergoing active development, but I believe the approach shows a lot of promise and is likely to be adopted by the OAuth working group soon. It works by creating a proof-of-possession signature over an access token or refresh token that would otherwise be a bearer token. And there’s already one implementation that I’m aware of — by Filip Skokan of Auth0. Let us know what you think of this new work!

The specification is available at:

An HTML-formatted version is also available at:

OAuth Device Flow spec renamed to “OAuth 2.0 Device Authorization Grant”

By

On March 11, 2019

In IETF, OAuth, Specifications

OAuth logoResponding to feedback from multiple parties that the title “OAuth 2.0 Device Flow for Browserless and Input Constrained Devices” was too much of a mouthful, the title of the specification has been simplified to “OAuth 2.0 Device Authorization Grant”. Likewise, we received feedback that “Device flow” was an insider term that caused more confusion than clarity, so its use has been removed from the specification. Finally, last minute feedback was received that client authorization and error handling were not explicitly spelled out. The specification now says that these occur in the same manner as in OAuth 2.0 [RFC 6749].

Many thanks to William Denniss for performing these edits! Hopefully this will be the draft that is sent to the RFC Editor.

The specification is available at:

An HTML-formatted version is also available at:

Page 2 of 11

Previous

Next

Powered by WordPress & Theme by Anders Norén