IndieAuth-extensions

IndieAuth extensions are IndieAuth extensions that are proposed, prototyped, or implemented beyond the official IndieAuth specification.

Why

IndieAuth is itself an OAuth2.0 extension, but it requires and incorporates several OAuth 2.0 extensions as part of the specification. OAuth 2.0 has a variety of proposed extensions itself that technically can be implemented as part of an implementation of IndieAuth.

IndieAuth has incorporated OAuth2.0 extensions into the specification, such as PKCE.

This page is for documenting such extensions to IndieAuth or for documenting OAuth2.0 extensions that have been implemented on IndieAuth endpoints and the considerations/modifications required to do so. These would be extensions that are not proposed as additions to the specification itself.

How to

Please use this page to document the list of current and proposed extensions, as well as document implementations of them. Development and discussion of the extensions should happen in a GitHub issue in the IndieAuth repo.

How to propose an extension

Please open a new issue here tagged with the extensions label if you would like to propose a new extension, then you can add a new section below to document your implementation of it here.

Stable Extensions

A stable extension is when a proposed extension has gotten multiple implementations from various people and/or organizations and is considered complete in functionality. This ensures that the extension works for a variety of use-cases and not just for a single project or company.

There are no stable extensions at this time.

Proposed Extensions

Anyone can create a proposed extension. A proposed extension should have an issue in the IndieAuth repository tagged with the extension label and a stub under this section.

Extensions may be given labels of their own under the repository as they develop.

Communication between Token and Authorization Endpoints

In 2020, the section describing communication between token endpoints and authorization endpoints was removed due underuse as in most cases, the two were tightly coupled.

This is described in the original W3C version of the IndieAuth spec.

If the token endpoint cannot verify the authorization code by other means, it MUST do so by verifying it with the authorization endpoint.

Ticketing

The Ticketing extension for IndieAuth is detailed under Ticketing_for_IndieAuth and describes a flow that enables a publisher to send authorization, known as a ticket, that can be redeemed for an access token. This allows both solicited and unsolicited invitations to fetch restricted resources.

Ticketing + ac-obo

• Specification
• Repository

David Somers [omz13] opted to expand on the idea of the Ticketing extension and write a complete specification document, which adds two additional flows. David Somers [omz13] refers to the existing grant flow, and the ticket endpoint flow, which is referred to in this proposal as ticket deposit.

• Ticket Wanted - which is a flow proposed in IndieAuth Issue 87 by fluffy
• AC-OBO - Authorization Code On-Behalf-Of grant flow, inspired by RFC8693

The Ticketing extension, with the two original flows remains an evolving extension proposal. Being as, depending on use case, you may or may not need or opt for the ability to request a ticket be issued, or the ability for a client to act on behalf of a a user, Ticketing+ac-obe is outlined here separately.