Mike Jones: self-issued

Musings on Digital Identity

Category: OAuth Page 3 of 11

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:

JWT BCP updates addressing Area Director review comments

By

On November 8, 2018

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

OAuth logoThe JSON Web Token (JWT) Best Current Practices (BCP) specification has been updated to address the review comments from Security Area Director (AD) Eric Rescorla. Thanks to Eric for the review and to Yaron Sheffer for working on the responses with me.

Note that IETF publication has already been requested. The next step is for the shepherd review to be submitted and responded to.

The specification is available at:

An HTML-formatted version is also available at:

The core Token Binding specs are now RFCs 8471, 8472, and 8473

By

On October 8, 2018

In IETF, OAuth, OpenID, Specifications, Token Binding

IETF logoThe IETF Token Binding working group has completed the core Token Binding specifications. These new standards are:

  • RFC 8471: The Token Binding Protocol Version 1.0
  • RFC 8472: Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation
  • RFC 8473: Token Binding over HTTP

As Alex Simons recently wrote, it’s time for token binding. Especially now that the core specs are done, now’s the time for platforms and applications to deploy Token Binding. This will enable replacing bearer tokens, which can be stolen and reused, with Token Bound tokens, which are useless if stolen. This is a huge security benefit applicable to any tokens used over TLS, including browser cookies, OAuth access tokens and refresh tokens, and OpenID Connect ID Tokens.

Congratulations especially to the editors Andrei Popov, Dirk Balfanz, Jeff Hodges, Magnus Nyström, and Nick Harper and the chairs John Bradley and Leif Johansson for getting this done!

I likewise look forward to timely completion of related Token Binding specifications, which enable use of Token Binding with TLS 1.3, with OAuth 2.0, and with OpenID Connect.

It’s Time for Token Binding

By

On August 21, 2018

In IETF, OAuth, OpenID, Specifications, Token Binding

IETF logoCheck out Alex Simons‘ and Pamela Dingle‘s blog post “It’s Time for Token Binding“. Now that the IETF Token Binding specs are essentially done, it’s time to ask those who write TLS software you use to ship Token Binding support soon, if they haven’t already done so.

Token Binding in a nutshell: When an attacker steals a bearer token sent over TLS, he can use it; when an attacker steals a Token Bound token, it’s useless to him.

OAuth 2.0 Authorization Server Metadata is now RFC 8414

By

On June 28, 2018

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

OAuth logoThe OAuth 2.0 Authorization Server Metadata specification is now RFC 8414. The abstract describes the specification as:

This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities.

The specification defines a JSON metadata representation for OAuth 2.0 authorization servers that is compatible with OpenID Connect Discovery 1.0. This specification is a true instance of standardizing existing practice. OAuth 2.0 deployments have been using the OpenID Connect metadata format to describe their endpoints and capabilities for years. This RFC makes this existing practice a standard.

Having a standard OAuth metadata format makes it easier for OAuth clients to configure connections to OAuth authorization servers. See https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#authorization-server-metadata for the initial set of registered metadata values.

Thanks to all of you who helped make this standard a reality!

OAuth Device Flow spec addressing initial IETF last call feedback

By

On June 1, 2018

In IETF, OAuth, Specifications

OAuth logoThe OAuth Device Flow specification (full name “OAuth 2.0 Device Flow for Browserless and Input Constrained Devices”) has been updated to address comments received to date from the IETF last call. Thanks to William Denniss for taking the pen for this set of revisions. Changes were:

  • Added a missing definition of access_denied for use on the token endpoint.
  • Corrected text documenting which error code should be returned for expired tokens (it’s “expired_token”, not “invalid_grant”).
  • Corrected section reference to RFC 8252 (the section numbers had changed after the initial reference was made).
  • Fixed line length of one diagram (was causing xml2rfc warnings).
  • Added line breaks so the URN grant_type is presented on an unbroken line.
  • Typos fixed and other stylistic improvements.

The specification is available at:

An HTML-formatted version is also available at:

JWT BCP updates addressing WGLC feedback

By

On May 9, 2018

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

OAuth logoThe JSON Web Token (JWT) Best Current Practices (BCP) specification has been updated to address the Working Group Last Call (WGLC) feedback received. Thanks to Neil Madden for his numerous comments and to Carsten Bormann and Brian Campbell for their reviews.

Assuming the chairs concur, the next step should be to request publication.

The specification is available at:

An HTML-formatted version is also available at:

Late-breaking changes to OAuth Token Exchange syntax

By

On April 24, 2018

In Claims, IETF, JSON, OAuth, Specifications

OAuth logoThe syntax of two JWT claims registered by the OAuth Token Exchange specification has been changed as a result of developer feedback. Developers pointed out that the OAuth Token Introspection specification [RFC 7662] uses a “scope” string to represent scope values, whereas Token Exchange was defining an array-valued “scp” claim to represent scope values. The former also uses a “client_id” element to represent OAuth Client ID values, whereas the latter was using a “cid” claim for the same purpose.

After consulting with the working group, the OAuth Token Exchange claim names have been changed to “scope” and “client_id“. Thanks to Torsten Lodderstedt for pointing out the inconsistencies and to Brian Campbell for seeking consensus and making the updates.

The specification is available at:

An HTML-formatted version is also available at:

OAuth Device Flow spec addressing Area Director comments

By

On April 23, 2018

In IETF, OAuth, Specifications

OAuth logoThe OAuth 2.0 Device Flow for Browserless and Input Constrained Devices specification has been updated to address feedback by Security Area Director Eric Rescorla about the potential of a confused deputy attack. Thanks to John Bradley for helping work out the response to Eric and to William Denniss for reviewing and publishing the changes to the draft.

The specification is available at:

An HTML-formatted version is also available at:

What Does Logout Mean?

By

On March 28, 2018

In Documentation, Events, Federation, OAuth, OpenID

OAuth logoDigital identity systems almost universally support end-users logging into applications and many also support logging out of them. But while login is reasonable well understood, there are many different kinds of semantics for “logout” in different use cases and a wide variety of mechanisms for effecting logouts.

I led a discussion on the topic “What Does Logout Mean?” at the 2018 OAuth Security Workshop in Trento, Italy, which was held the week before IETF 101, to explore this topic. The session was intentionally a highly interactive conversation, gathering information from the experts at the workshop to expand our collective understanding of the topic. Brock Allen — a practicing application security architect (and MVP for ASP.NET/IIS) — significantly contributed to the materials used to seed the discussion. And Nat Sakimura took detailed notes to record what we learned during the discussion.

Feedback on the discussion was uniformly positive. It seemed that all the participants learned things about logout use cases, mechanisms, and limitations that they previously hadn’t previously considered.

Materials related to the session are:

JWT BCP draft adding Nested JWT guidance

By

On March 23, 2018

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

OAuth logoThe JSON Web Token (JWT) Best Current Practices (BCP) specification has been updated to add guidance on how to explicitly type Nested JWTs. Thanks to Brian Campbell for suggesting the addition.

The specification is available at:

An HTML-formatted version is also available at:

OAuth Authorization Server Metadata spec addressing additional IESG feedback

By

On March 4, 2018

In Claims, IETF, JSON, OAuth, Specifications

OAuth logoThe OAuth Authorization Server Metadata specification has been updated to address additional IESG feedback. The only change was to clarify the meaning of “case-insensitive”, as suggested by Alexey Melnikov.

The specification is available at:

An HTML-formatted version is also available at:

Page 3 of 11

Previous

Next

Powered by WordPress & Theme by Anders Norén