Client Discovery / Automatic Registration in OAuth2/OIDC

Tobias Looker, Mike Jones and Kristina Yasuda

The Problem

With conventional OAuth2 (and OpenID Connect which is built atop), a prerequisite for the client to interact with the AS/OP is that it must have a valid “client_id”. It is typical assigned by the AS/OP ahead of time.

While powerful, this model is unwieldy or unworkable for some use cases, such as:

• Large-scale identity federations
• Other models like OpenID for Verifiable Credentials

The Problem

The Importance of the Client

Why don’t we just make the client anonymous in the protocol? E.g., no client_id

• The client is an important party in the OAuth2 protocol who the AS/OP often needs to know things about to
• Establish trust in it
• Understand its capabilities

The challenge to solve is how the client can identify itself and provide information about itself without having to first register at the AS/OP

Why not Dynamic Client Registration?

As defined by RFC 7591 why not just use this?

In short there are unresolved challenges:

• How the AS/OP protects malicious registration attempts but preserves an open model.
• Too complex for clients having to manage a client ID per AS/OP and registering if not already
• Dead registration records on the AS/OP caused by client storage limitations (e.g SPA’s)

The Solution Approach

A model where instead of the client using an identifier assigned by the AS/OP, using one that is assigned and managed by the client itself, a URL.

aHdehcTiVjcKtoMgn

https://client.example.com

From

To

Prior Art / Precedents

• OpenID Connect Federation has already defined a mechanism that does this, known as “Automatic Registration”
• IndieAuth uses something similar for simpler login use cases
• SIOPv2 uses “Automatic Registration” for non-pre-registered clients

In short, there is market validation for the pattern.

​

Automatic Registration Challenges

• Automatic Registration (as defined in OpenID Connect Federation) is difficult for developers to grok as a general non-pre-registered OAuth 2.0 client identification solution because
• The Automatic Registration (and Entity Statement) definitions are only a small subset of the functionality defined in the spec
• While independently usable from the rest, that may not be apparent
• While designed to be usable for OAuth 2.0 clients as well as OpenID Connect RPs, that may also not be apparent

​

One Tried-and-True Approach

• Write an OAuth draft that extracts only what OAuth 2.0 clients need to use Automatic Registration from the OpenID Connect Federation spec
• We have a long history of brining solutions created by Connect to OAuth
• RFC 7591 is compatible with OpenID Connect Dynamic Client Registration
• RFC 8414 is compatible with OpenID Connect Discovery
• RFC 9101 is compatible with OpenID Connect Request Objects
• We could do the same thing again!

​

Federation Entity Statement

• Self-asserted metadata about the Entity (Client)
• Retrieved from <client_id>/.well-known/openid-federation
• “sub” claim value in the Entity Statement is the Client Identifier
• Proves control of the identifier

​

• See example Entity Statement contents at the end of https://openid.net/specs/openid-connect-federation-1_0-24.html#name-entity-statement

A Possible Starting Point

OAuth2 Client Discovery draft, which defines:

• How a client can communicate with an AS/OP using a client_id set to the value of a URL it manages/controls and how to host this metadata in a resolvable manner.
• How an AS/OP can use this URL based client_id and resolve it to the clients metadata, e.g “discover” information about the client. Note It does not mandate when this discovery occurs, it may be JIT or done prior to interaction with the client.

(Note that it’s not 100% compatible with Automatic Registration at present)

Example Discovery Request

Client ID: https://client.example.com

Metadata Location: https://client.example/com/.well-known/oauth-client

HTTP Get

Example Authorization Request

Client ID as encoded URL

New Parameter indicating the client ID is an encoded URL

Example Token Request

Client ID as URL

New Parameter indicating the client ID is a URL

A note on terminology difference?

Client discovery vs Automatic Registration

OAuth2 Client Discovery deliberately does not use language like “registration” because in the suggested model, the client is never registered with the AS/OP, instead discovered as required.

Another viewpoint is that “client registration” happens when the AS retrieves the client’s metadata

​

Further points of discussion

• Should the draft define the usage of attestations about the client in the client’s metadata so the AS/OP can establish trust in the client indirectly (e.g., entity attestations from openid federation)
• Other features …?