Transactional Authentication (Page-level auth tokens)

Overview

Improve the support for transactional approaches in the authentication framework. The current implementation of authentication tokens is more suited to a portal approach than a transactional one.

See this snippet for the background describing how to use authenticated links with forms. This documents the resulting conversation with @totten here:

(@totten says:) I'd like some language to describe two ways of approaching customized UX for constituents.

Hypothetical scenario
- You send an email 12 months after a prior donation. You thank the donor for the previous contribution. The message includes some links to update communication preferences, browse past donations, or make a new donation.
UX Approaches
1. Transactional Approach / One form at a time / Strict Pageflow / Page-Level Auth: The email has 3x hyperlinks. Each goes to different form/page. Each link has diff auth code (which confers access to exactly one form).
2. Portal Approach / Multiple forms at discretion / Open Pageflow / Session-Level Auth: The email has 3x hyperlinks. All go to pages within the same portal. The user opens the first page which takes their interest. On that page, there are more links (eg via prose or navbar) to go checkout the others.

I don't know a good/simple way to say that one is better than the other. but they are different. I suspect there's some Venn diagram of organizational-scenarios (some better suited to 1; some to 2; some to either 1 or 2)

The current auth-code mechanism is better for "Portal Approach/Open Pageflow" -- and it's worse for Transactional Approach/Strict Pageflow" (that's not b/c "Open Pageflow" is better -- but at the time of its writing, it was the easier one to support)

From a low-level POV, the auth-codes for them would differ like this:

For portal/open pageflow, it generates this token -- which is basically a login-token
- -The custom forms use "Role-based" security-(Maybe either security model is ok in this context...)

For transactional/strict pageflow, you might expect...

It needs a fine-grained token like this (pseudocode)

  $bearerToken = "Bearer " . $jwt->encode([
      'exp' => $expires,
      'sub' => "cid:" . $contactId,
      'scope' => 'api4',
      'api4.whitelist' => [
        ['Afform', 'prefill', ['name' =>'xyz']],
        ['Afform', 'submit', ['name' =>'xyz']],
    ]);

In PHP, need a mechanism to accept those tokens
In JS/HTML, need a mechanism to relay that token
The custom forms use "Form-based" security

Transactional Authentication (Page-level auth tokens)

Overview

See also