If you want to allow anonymous clients to start builds of jobs, you can include a secret "build token" in the URL rather than authentication. The Build Token Root plugin extends this system to work even in a Jenkins system that denies anonymous read permission to the job.

Build token URLs also accept GET requests, which makes for simpler client calls—POST requests must normally be accompanied by a crumb obtained separately, to defend against CSRF attacks.

For Pipeline input steps sometimes it is desirable to allow selected people to approve (or cancel) the step without accessing the Jenkins web UI, for example by clicking a link in a mail message. You can already direct them to the step's UI page

mail body: """
Please <a href="${env.BUILD_URL}input/">approve me</a>!
""", ...

but they will generally need to log in (if there is no active browser session), and then click a button. While this is probably appropriate for cases where parameters are being requested, for simple OK/Cancel inputs it could be too onerous.

Links to .../input/TheID/proceedEmpty will not work, even if the link includes a username and API token (dangerous!), since this endpoint requires POST requests (and thus, generally, crumbs) to prevent XSS attacks.

You may also want simple access to a secret URL to suffice to take actions, without requiring the script to define a submitter group that maps precisely to a security realm.

For these reasons it would be useful to add an optional parameter to input, say token, which would be a secret textual value that could be used to approve or cancel the step via a GET request to a URL defined using UnprotectedRootAction. For example given

def tok = UUID.randomUUID().toString()
mail to: 'admins@mycorp', subject: 'Ready to roll?', mimeType: 'text/html', body: """
Please <a href="${env.JENKINS_URL}pipeline-inputs/${tok}/proceed">approve me</a>!
"""
input message: 'Ready?', token: tok

then clicking the link, or more explicitly

curl -s http://jenkins/pipeline-inputs/abcdef12345678/proceed

would suffice to let the build continue. This should probably return a 204 No Content.

abort would work the same way. There could also be a submit that parses query parameters much like ParametersDefinitionProperty.buildWithParameters, using ParameterDefinition.createValue(StaplerRequest), in case you wanted to send distinct links with various options, for example.

Once the input step completes, the token is no longer valid to change the outcome. The step can allow a previously used token to be reused, but an attempt to specify a token which is already in use by another running input step should result in an error, so it is best to randomly generate the token, as above—unless the job setup is such that you can guarantee that there is only ever one running input step for this job, and wish to create a permalink/bookmark.