Class OAuthMetadataAddresses

Namespace

MailFathom.Common.OAuth

Assembly

MailFathom.Common.dll

Where an authorization server's metadata is looked for, given only its issuer.

public static class OAuthMetadataAddresses

Inheritance

object

OAuthMetadataAddresses

Inherited Members

object.Equals(object)

object.Equals(object, object)

object.GetHashCode()

object.GetType()

object.MemberwiseClone()

object.ReferenceEquals(object, object)

object.ToString()

Remarks

A resource server needs two things from an authorization server: the issuer it will compare a token's iss against, and the key set it will check a signature against. Both come out of a discovery document, and no endpoint is ever assembled by hand — a hard-coded /jwks or /token would be a guess about one server's layout that happens to hold until it does not.

What is not settled is where that document lives, because two specifications place it differently. OAuth 2.0 Authorization Server Metadata inserts its well-known segment between the issuer's authority and its path, while OpenID Connect Discovery historically appends it to the whole issuer, and a server may publish either or both. The MCP authorization specification resolves this by naming an order to try rather than a single location, and that order is what this produces: the OAuth form first, then the OpenID Connect form with the same path insertion, then the appended form that older OpenID providers serve.

Every candidate is derived from the configured issuer and therefore reaches only the server the profile already names. Nothing a token carries influences any of them, which is what keeps discovery from becoming a way to make the host fetch an address chosen by whoever sent a request.

Methods

ForIssuer(string?)

Reports where the discovery document for an issuer is looked for, in the order the MCP authorization specification names.