Skip to main content
The second scenario besides sign-in: the user fills in a form — a request, a question, a callback request form — and confirms the submission in a messaging app. Next to the submission you get a record saying “this was confirmed by this subject in this channel”, and no session is created and no account is provisioned.
The handler fits in about 250 lines of PHP, with no Composer and no external dependencies; verified on the Telegram channel.

​
Why this is not a sign-in setting

No OIDC plugin for any CMS does this. Plugins cover signing in to an account, while Contact Form 7, WPForms and Bitrix web forms are not tied to an account at all. “A member area” and “a confirmed submission” are two different solutions, not two settings of one.
So there is no plugin and no CMS recipe here: what you need is a small server-side handler placed next to the form.

​
Why the handler must be server-side

A browser-only script cannot do it, and it runs into three walls at once:
  • only the Authorization Code Flow (plus refresh) is supported — there is no implicit and no hybrid;
  • no endpoint has CORS configured;
  • the access token is an opaque identifier, and introspecting it takes a confidential client with a secret, which a browser script cannot keep.
The practical consequence for SaaS site builders (Tilda, Wix, Shopify): the scenario needs hosting for that handler — the builder page alone is not enough.

​
The flow

  1. the user clicks the button under the form;
  2. a redirect to /connect/authorize with PKCE S256, state and nonce — plus acr_values if you want a specific channel;
  3. the return to redirect_uri, an ordinary page of your site;
  4. the server exchanges the code for tokens and validates iss, aud, exp and nonce;
  5. the submission gets a record: “confirmed: sub + channel_type”;
  6. no authentication cookie is set — nobody signs in.

​
About signature validation

Validating the id_token signature with a JWT library is not required here: OIDC Core §3.1.3.7, rule 6 lets a client that obtained the token directly from the token endpoint rely on TLS verification instead of checking the signature. That is why the handler needs no JWT library and no Composer.
The relaxation has a price, and it is not negotiable: TLS certificate verification must never be switched off (CURLOPT_SSL_VERIFYPEER in PHP stays on). Without it, the very thing the permission rests on disappears.

​
Your own buttons on your own page

The two buttons under the form — “via Telegram” and “any channel” — are a parameter of the authorize request: acr_values=channel:telegram narrows the choice to one channel, and without the parameter the user picks.
There is no widget or JS SDK for this, and none is needed: “your own button” is a link with the right parameters, not an embeddable component.