OAuth2/OIDC & Consented Social Publishing

A successful sign-in is not permission to publish

A learner connects a professional social account and wants to share a completed portfolio item. The browser has a valid OpenID Connect session. The application also has an older access token and remembers that a posting scope was granted earlier. The new post draft, however, has changed since the last human approval.

That combination is exactly where unsafe shortcuts appear. Authentication answers who signed in. OAuth authorization answers what delegated access the client currently has. A provider-specific publishing permission answers which resource action is permitted for which actor. MAKNOW's own consent and approval state answers whether this exact content may cause a side effect now. None of those layers can safely substitute for the others.

This lesson builds Consented Social Identity & Publishing Contract v1. It keeps the connection, subject, scopes, consent, token lifecycle, approved content, publishing actor, provider permission, provider version, revocation/reauthorization state, audit evidence and provenance separate. The strongest successful outcome is still a bounded human publish review; this lesson does not perform a live publish.

For: learning-platform engineers, identity/integration teams, social-publishing product owners, security reviewers and evidence-governance owners. Not for: storing real production tokens in a lab, automating a live social post, treating login as consent, or defining a provider's legal terms of use.

Route orientation and ownership boundary

MKN-017 owns the connection/consent/publish evidence boundary. Its hard prerequisite is MKN-003. MKN-016 owns effort estimation; MKN-018 owns career role/skill extraction. This lesson may hand a clean identity-and-authority record downstream, but it does not estimate delivery effort or infer career competency.

Foundation learners should track one member-account scenario through the fields. Repair learners should stop at the first invalid authority state and name the smallest safe repair. Experienced learners should defend least privilege, subject/actor binding, content-approval binding, provider-version evidence and revocation propagation under transfer.

Checkpoints: F1 separate OIDC authentication from OAuth/provider authorization; F2 diagnose a valid session with missing publish scope; F3 revoke the member permission and rebuild the decision for an organization actor with a new role and scope set.

Mental model: identity → delegated authority → local consent → content approval → preflight → side effect

Use this ordered flow:

OIDC authentication → authorization-code flow + PKCE → provider consent/scopes → token lifecycle → MAKNOW consent ledger → exact content approval → actor/role + provider-version preflight → human publish confirmation → provider reference + audit → revoke/reauthorize on change

A valid ID Token or session establishes an authenticated identity context; it does not create a posting permission. An access token is a credential container; its mere presence does not prove that the needed scope is current, that consent is current, that the actor still has the provider role, that the token is unexpired, or that the approved content still matches the bytes about to be published.

Useful bounded states include PUBLISH_REVIEW_REQUIRED, HOLD_IDENTITY_BINDING, HOLD_PUBLISH_SCOPE, HOLD_CONSENT, HOLD_TOKEN_REAUTH, HOLD_CONTENT_APPROVAL, HOLD_ACTOR_AUTHORITY, HOLD_PROVIDER_VERSION, HOLD_REVOKED, HOLD_TOKEN_SECURITY, HOLD_AUDIT_PROVENANCE, and HOLD_BASELINE_ORACLE_REUSE.

Foundation contract: seventeen evidence dimensions before any publish side effect

The frozen dimensions are connection_id, provider_id, oidc_subject_ref, authentication_state, requested_scope, granted_scope, consent_record_ref, token_expiry, refresh_state, content_approval_state, publish_actor, publish_permission, provider_post_ref, revocation_state, reauthorization_required, audit_event_ref, and provenance.

Minimum invariants:

1. The OIDC subject is bound to the exact connection/provider record; identity is not inferred from a display name or email alone.
2. Requested and granted scopes are stored separately; extra scope is not silently treated as necessary.
3. The required provider publish permission is explicit for the intended actor type.
4. The consent record identifies the connection, requested/granted scope set and the decision time/version.
5. Access-token material is never placed in learner evidence; the package records only synthetic token state such as expiry/refresh status.
6. Expired or non-refreshable authority becomes reauthorization work, not a hidden retry.
7. Human approval is bound to the exact content reference/hash/version to be published.
8. Member and organization actors are different authority contexts; role evidence is rechecked for organization publishing.
9. Revocation invalidates publish authority even if a local OIDC session remains valid.
10. Provider API/version requirements are checked again before the side effect.
11. No provider post reference exists before the side effect; a preflight record must not fabricate one.
12. Audit/provenance must reconstruct actor, connection, consent, content approval, authority checks and resulting bounded state.

Deep explanation: three authorities that must not collapse

OpenID Connect — FACT. OpenID Connect Core describes OIDC as an identity layer on top of OAuth 2.0. A client can verify an end-user identity and obtain claims. That identity result is not, by itself, an authorization to create a social post.

OAuth security — FACT. RFC 9700 is the OAuth 2.0 Security Best Current Practice. Among its current protections, authorization servers use exact redirect-URI matching (with the documented localhost exception), public clients use PKCE, confidential clients are recommended to use PKCE, and less secure patterns are deprecated or constrained. This is protocol-security guidance; it does not define MAKNOW's consent labels or content-approval workflow.

LinkedIn Posts API — FACT and provider example. Current Microsoft/LinkedIn documentation identifies w_member_social for posting on behalf of an authenticated member and w_organization_social for organization publishing, with organization permissions constrained by page roles. The Posts API also requires a Linkedin-Version request header in YYYYMM form. Those facts illustrate provider-specific authorization and versioning; another provider can have different scopes, roles and review rules.

MAKNOW — DESIGN. The consent ledger, least-privilege scope request, exact content approval, no-publish-on-ambiguity, revocation propagation, reauthorization trigger, audit event and human publish review are local product/governance authority. External standards and vendor docs do not grant MAKNOW permission to publish.

Worked examples

Example A — member account, evidence complete but side effect still human-controlled

Connection CONN-17-A authenticates subject sub:learner-42. The OAuth request asked for openid profile w_member_social; the provider granted those scopes; the consent ledger is current; the synthetic token state is unexpired; the final content hash is approved; the actor is the same member; the provider version is current; revocation is clear; audit/provenance are present. The bounded outcome is PUBLISH_REVIEW_REQUIRED: the evidence supports a human-visible publish confirmation, not an automatic post.

Example B — the dangerous shortcut

The OIDC session is still valid, but w_member_social is absent from the current granted scope set. A UI that says “Connected” is not evidence of publish authority. The correct state is HOLD_PUBLISH_SCOPE; the repair is a new, explicit authorization request/consent path for the needed least-privilege permission—not reuse of the old session.

Example C — consent revoked after approval

The exact draft was approved, but the provider permission is revoked before the side effect. Content approval survives as historical evidence; publish authority does not. The decision becomes HOLD_REVOKED with reauthorization_required=true. Reapproval of content may or may not be needed depending on whether its bytes changed, but reauthorization definitely is.

Example D — organization transfer

The learner reconnects using an organization account. Even if the same human is authenticated, the actor is now an organization and the provider requires organization-specific permission plus an eligible page role. Rebuild connection, scope, consent, actor-role and approval evidence. Do not copy the member-account result.

Failure modes that must fail closed

• OIDC session valid, publish scope absent → HOLD_PUBLISH_SCOPE.
• Consent record missing, stale or for a different scope set → HOLD_CONSENT.
• Token expired and no valid refresh path → HOLD_TOKEN_REAUTH.
• Final draft changed after approval → HOLD_CONTENT_APPROVAL.
• Member scope reused for organization publishing or organization role absent → HOLD_ACTOR_AUTHORITY.
• Provider permission is revoked while local sign-in remains valid → HOLD_REVOKED.
• Provider API/version evidence is stale or no longer supported → HOLD_PROVIDER_VERSION.
• OIDC subject cannot be bound to this connection → HOLD_IDENTITY_BINDING.
• Token secret appears in learner-facing evidence or is marked insecurely handled → HOLD_TOKEN_SECURITY.
• Audit/provenance cannot reconstruct the preflight → HOLD_AUDIT_PROVENANCE.
• Organization transfer copies the member result instead of recomputing → HOLD_BASELINE_ORACLE_REUSE.

Alternatives and trade-offs

One broad scope request. Easier setup, worse least privilege and harder consent explanation. Prefer the smallest provider scope set that supports the intended action.

Connect identity now, request publish permission later. More steps, but it cleanly separates sign-in from a future side effect and can reduce over-collection.

Long-lived connection with refresh. Better continuity, but revocation, expiry, storage and provider changes need stronger monitoring and evidence. Refresh capability is not perpetual authority.

Just-in-time reauthorization. More user friction, but makes current permission and intent visible at the point of action.

Automatic publish after content approval. Operationally convenient, but this lesson deliberately requires a human-visible confirmation before the external side effect. The approval record and the final publish confirmation are related but distinct controls.

Experienced bridge: four bindings worth defending

First, bind identity to connection. Subject, issuer/provider and connection record must line up; UI account names are insufficient.

Second, bind authorization to action. A token with generic or stale permissions is not evidence that the required posting action is currently delegated.

Third, bind approval to content. Approval of draft v3 cannot authorize draft v4 after text, media or visibility changes.

Fourth, bind actor to provider role/version. Member publishing and organization publishing are not interchangeable. A provider API migration can also invalidate a previously working request even when token data looks unchanged.

A robust design therefore treats reauthorization as a state transition with evidence, not as a background technical fix. Historical consent remains historical; a new authorization event creates new evidence rather than rewriting the past.

Guided and independent practice

Guided: Open lab://MKN-017/MKN-017-LAB1. Start with the baseline member-account fixture. Fill Consented Social Identity & Publishing Contract v1 from the visible synthetic evidence and explain why the ceiling is PUBLISH_REVIEW_REQUIRED rather than “published.”

Repair: Change only one dimension at a time: remove w_member_social, expire the token, revoke consent, change the content hash after approval, remove the organization role, or make provider-version evidence stale. Re-run only the relevant decision path and identify the minimal repair.

Independent: Use the transfer fixture. Revoke the member connection, then create the organization connection from its own subject/actor/scope evidence. The member result is not an oracle. The organization must establish w_organization_social (or the provider-equivalent current permission), eligible role evidence, new consent and current approval before it can reach human publish review.

Verification evidence: what a reviewer must be able to reconstruct

A reviewer should be able to reconstruct the connection identifier, provider, OIDC subject reference and authentication state; requested versus granted scope; consent record; token expiry/refresh state; exact approved content; publishing actor and provider permission; provider version/role evidence; revocation/reauthorization state; audit event and provenance.

The reviewer should also be able to prove the negative boundaries: valid sign-in did not compensate for missing publish scope; revoked consent stopped the action; content mutation invalidated approval; organization publishing was recomputed; no token secret was placed in learner evidence; and no provider post reference was invented before a side effect.

If decisive evidence is missing, stale or contradictory, the record stays in a typed non-success state. Verification means reproducible evidence—not trust in hidden reasoning or a “connected” badge.

Assessment and transfer

S1: Explain the owned boundary and one non-goal. S2: Build Consented Social Identity & Publishing Contract v1 for the baseline member fixture. S3: Keep the OIDC session valid but remove the publish permission; name the invalidated fields, resulting state and minimal safe repair. S4: Revoke the member permission, then reconnect as an organization account with a different role/scope set and rebuild the authority/approval decision from the new evidence.

Blocking misconception: “If social sign-in works or an access token exists, the application may post.”

AI may organize the supplied synthetic evidence and run deterministic checks. It may not invent consent, provider scopes, organization roles, token validity, content approval, real credentials, provider post references or permission to execute a live side effect.

References, freshness and authority boundary

• OpenID Connect Core — FACT: OIDC remains an authentication layer on top of OAuth 2.0 and communicates identity claims; it is not a generic publishing authorization.
• RFC 9700 — FACT: current OAuth 2.0 Security BCP; exact redirect-URI matching and PKCE-related protections remain current. It does not define MAKNOW consent or content approval.
• LinkedIn Posts API — FACT/provider example: current documentation lists w_member_social and w_organization_social, organization-role constraints and versioned request headers. These details are provider-specific and can change.
• MAKNOW design: consent ledger, least privilege, exact content approval, revoke/reauthorize rules and human publish review remain local authority.

Freshness was rechecked on 2026-09-13. Re-review by 2027-01-15, or earlier if OAuth/OIDC security guidance, provider permissions, publishing APIs or version policy materially change.