OAuth2/OIDC و Consented Social Publishing

ورود موفق یعنی اجازهٔ انتشار نیست

یک learner حساب حرفه‌ای اجتماعی خود را وصل کرده و می‌خواهد یک portfolio item تکمیل‌شده را منتشر کند. مرورگر یک session معتبر OpenID Connect دارد. سامانه یک access token قدیمی هم می‌شناسد و در سابقه دیده می‌شود که قبلاً scope مربوط به posting داده شده است. اما متن نهایی post بعد از آخرین approval انسانی تغییر کرده است.

این دقیقاً جایی است که shortcut خطرناک شکل می‌گیرد. authentication می‌گوید چه کسی وارد شده. OAuth authorization می‌گوید client اکنون چه دسترسی delegated دارد. provider-specific publishing permission می‌گوید برای کدام actor چه actionای مجاز است. consent و approval خود MAKNOW نیز می‌گوید آیا همین محتوای مشخص اکنون اجازهٔ ایجاد side effect دارد یا نه. هیچ‌کدام جانشین دیگری نیست.

در این درس Consented Social Identity & Publishing Contract v1 می‌سازیم: connection، subject، scopeها، consent، token lifecycle، محتوای approveشده، publish actor، provider permission، provider version، revoke/reauthorize، audit و provenance را جدا نگه می‌داریم. حتی در بهترین حالت، خروجی فقط به human publish review می‌رسد؛ این درس هیچ post زنده‌ای منتشر نمی‌کند.

مناسب برای: مهندسان learning platform، تیم identity/integration، ownerهای social publishing، security reviewer و evidence-governance. نامناسب برای: ذخیرهٔ token واقعی در Lab، publish واقعی، یکی‌گرفتن login با consent یا تعریف terms provider.

جهت مسیر و مرز مالکیت

MKN-017 فقط مرز evidence مربوط به connection/consent/publish را مالک است. پیش‌نیاز hard آن MKN-003 است. MKN-016 effort estimation را مالک است و MKN-018 role/skill extraction را. این درس می‌تواند یک رکورد تمیز identity-and-authority به مراحل بعد بدهد، اما زمان تحویل یا competency شغلی را تعیین نمی‌کند.

learner پایه یک سناریوی member account را fieldبهfield دنبال می‌کند. learner repair باید در اولین authority state نامعتبر توقف کند و کوچک‌ترین repair امن را بگوید. learner باتجربه باید least privilege، subject/actor binding، content-approval binding، provider-version evidence و revocation propagation را در Transfer دفاع کند.

Checkpointها: F1 تفکیک OIDC authentication از OAuth/provider authorization؛ F2 تشخیص session معتبر همراه با publish scope گمشده؛ F3 revoke کردن member permission و بازسازی تصمیم برای organization actor با role و scope جدید.

مدل ذهنی: identity → delegated authority → local consent → content approval → preflight → side effect

این ترتیب را حفظ کنید:

OIDC authentication → authorization-code + 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

ID Token یا session معتبر فقط context هویتی می‌دهد؛ permission ساخت post ایجاد نمی‌کند. access token صرفاً credential است؛ وجود آن ثابت نمی‌کند scope لازم هنوز جاری است، consent هنوز معتبر است، actor هنوز role مناسب دارد، token منقضی نشده، یا bytes محتوای approveشده با چیزی که قرار است publish شود یکسان است.

stateهای مفید شامل 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 و HOLD_BASELINE_ORACLE_REUSE هستند.

قرارداد پایه: هفده بُعد evidence پیش از هر publish side effect

ابعاد فریز‌شده عبارت‌اند از 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 و provenance.

حداقل invariantها:

1. OIDC subject باید به connection/provider دقیق bind باشد؛ display name یا email به‌تنهایی identity proof نیست.
2. requested و granted scope جدا ثبت می‌شوند؛ scope اضافه silently «ضروری» تلقی نمی‌شود.
3. permission لازم برای actor موردنظر باید صریح باشد.
4. consent record باید connection، scope set و زمان/نسخهٔ تصمیم را مشخص کند.
5. token secret هرگز وارد learner evidence نمی‌شود؛ فقط state مصنوعی مانند expiry/refresh ثبت می‌شود.
6. token منقضی یا غیرقابل-refresh به reauthorization تبدیل می‌شود، نه retry پنهان.
7. human approval باید به content ref/hash/version دقیق bind باشد.
8. member و organization دو authority context متفاوت‌اند؛ organization role دوباره بررسی می‌شود.
9. revocation باید publish authority را باطل کند حتی اگر OIDC session هنوز معتبر است.
10. provider API/version requirement پیش از side effect دوباره check می‌شود.
11. provider post ref قبل از side effect وجود ندارد؛ preflight حق ساخت ref جعلی ندارد.
12. audit/provenance باید actor، connection، consent، content approval، authority checks و bounded state را بازسازی کند.

توضیح عمیق: سه authority که نباید collapse شوند

OpenID Connect — FACT. OIDC Core، OpenID Connect را identity layer روی OAuth 2.0 تعریف می‌کند. client می‌تواند هویت end-user و claimها را verify کند. این نتیجهٔ هویتی به‌خودی‌خود authorization برای ساخت social post نیست.

OAuth security — FACT. RFC 9700، OAuth 2.0 Security Best Current Practice است. از جمله exact redirect-URI matching را الزام می‌کند، برای public clientها PKCE را لازم می‌داند و برای confidential clientها نیز PKCE را توصیه می‌کند؛ الگوهای ضعیف‌تر را محدود یا deprecated می‌کند. این security guidance است و consent UX یا content approval MAKNOW را تعریف نمی‌کند.

LinkedIn Posts API — FACT و مثال provider. مستندات فعلی Microsoft/LinkedIn برای posting از طرف member، w_member_social و برای organization، w_organization_social را نشان می‌دهد؛ permission سازمانی به page role نیز وابسته است. Posts API همچنین header نسخهٔ Linkedin-Version با قالب YYYYMM می‌خواهد. این facts نشان می‌دهد authorization و versioning provider-specific هستند؛ provider دیگر می‌تواند scope و role دیگری داشته باشد.

MAKNOW — DESIGN. consent ledger، least-privilege scope، exact content approval، no-publish-on-ambiguity، revocation propagation، reauthorization trigger، audit event و human publish review authority محلی محصول هستند. استاندارد یا vendor documentation به‌تنهایی اجازهٔ publish به MAKNOW نمی‌دهد.

مثال‌های کارشده

مثال A — member account با evidence کامل ولی side effect همچنان انسانی

connection CONN-17-A، subject sub:learner-42 را authenticate می‌کند. OAuth request شامل openid profile w_member_social بوده، provider همین scopeها را grant کرده، consent جاری است، token synthetic منقضی نشده، final content hash approve شده، actor همان member است، provider version جاری است، revocation نداریم و audit/provenance حاضر است. state درست PUBLISH_REVIEW_REQUIRED است: evidence فقط human-visible publish confirmation را مجاز می‌کند، نه auto-post.

مثال B — shortcut خطرناک

OIDC session هنوز معتبر است، ولی w_member_social در granted scope جاری نیست. badge «Connected» evidence برای publish authority نیست. state درست HOLD_PUBLISH_SCOPE است. repair، authorization/consent جدید و صریح برای least-privilege permission لازم است، نه reuse کردن session قدیمی.

مثال C — revoke بعد از approval

draft دقیق approve شده، اما permission provider پیش از side effect revoke می‌شود. content approval به‌عنوان evidence تاریخی باقی می‌ماند، ولی publish authority نه. تصمیم HOLD_REVOKED و reauthorization_required=true است. اگر content تغییر نکرده شاید reapproval لازم نباشد، اما reauthorization قطعاً لازم است.

مثال D — انتقال به organization

learner با organization account reconnect می‌کند. حتی اگر همان انسان authenticate شده، actor این بار organization است و provider scope سازمانی و role واجد شرایط می‌خواهد. connection، scope، consent، actor-role و approval را از نو بسازید. نتیجهٔ member account قابل‌کپی نیست.

Failure modeهایی که باید fail-closed شوند

• OIDC session معتبر و publish scope غایب → HOLD_PUBLISH_SCOPE.
• consent record غایب/stale یا مربوط به scope set دیگر → HOLD_CONSENT.
• token منقضی و refresh path معتبر ندارد → HOLD_TOKEN_REAUTH.
• final draft بعد از approval تغییر کرده → HOLD_CONTENT_APPROVAL.
• member scope برای organization reuse شده یا organization role غایب است → HOLD_ACTOR_AUTHORITY.
• permission provider revoke شده ولی sign-in محلی معتبر مانده → HOLD_REVOKED.
• provider API/version evidence stale یا unsupported است → HOLD_PROVIDER_VERSION.
• OIDC subject به connection bind نمی‌شود → HOLD_IDENTITY_BINDING.
• token secret داخل learner evidence دیده می‌شود یا handling ناامن علامت خورده → HOLD_TOKEN_SECURITY.
• audit/provenance preflight را بازسازی نمی‌کند → HOLD_AUDIT_PROVENANCE.
• Transfer organization نتیجهٔ member را کپی می‌کند → HOLD_BASELINE_ORACLE_REUSE.

Alternativeها و trade-offها

درخواست یک scope set گسترده از ابتدا. setup ساده‌تر، least privilege ضعیف‌تر و consent سخت‌تر برای توضیح. scope set کوچک‌تر برای action مشخص بهتر است.

اتصال identity اکنون، درخواست publish permission هنگام نیاز. step بیشتر دارد، ولی sign-in را از side effect آینده جدا می‌کند و over-collection را کاهش می‌دهد.

connection بلندمدت با refresh. continuity بهتر، اما revocation، expiry، storage و provider change به evidence قوی‌تر نیاز دارند. refresh capability یعنی امکان renewal، نه permission دائمی.

just-in-time reauthorization. friction بیشتر، ولی current intent و current permission را نزدیک action نشان می‌دهد.

auto-publish بعد از content approval. operationally راحت است، اما این درس human-visible confirmation را قبل از external side effect نگه می‌دارد. approval record و final publish confirmation دو control مرتبط ولی جدا هستند.

پل باتجربه‌ها: چهار binding که ارزش دفاع دارند

اول identity را به connection bind کنید. subject، issuer/provider و connection record باید هم‌راستا باشند؛ account name نمایشی کافی نیست.

دوم authorization را به action bind کنید. token عمومی یا stale evidence کافی برای posting action جاری نیست.

سوم approval را به content bind کنید. approval draft v3، draft v4 را بعد از تغییر text/media/visibility authorize نمی‌کند.

چهارم actor را به provider role/version bind کنید. member publishing و organization publishing قابل‌جایگزینی نیستند. migration API provider نیز می‌تواند request قبلی را نامعتبر کند، حتی اگر token state ظاهراً تغییر نکرده باشد.

طراحی قوی reauthorization را یک state transition با evidence می‌بیند، نه fix پس‌زمینه. consent تاریخی rewrite نمی‌شود؛ authorization جدید evidence جدید تولید می‌کند.

تمرین هدایت‌شده و مستقل

Guided: lab://MKN-017/MKN-017-LAB1 را باز کنید. از fixture member baseline شروع کنید. Consented Social Identity & Publishing Contract v1 را از evidence synthetic پر کنید و توضیح دهید چرا ceiling برابر PUBLISH_REVIEW_REQUIRED است، نه «published».

Repair: هر بار فقط یک dimension را عوض کنید: w_member_social را حذف کنید، token را expire کنید، consent را revoke کنید، content hash را بعد از approval تغییر دهید، organization role را حذف کنید یا provider-version evidence را stale کنید. فقط path مرتبط را rerun و minimal repair را نام ببرید.

Independent: از Transfer استفاده کنید. member connection را revoke کنید و organization connection را فقط از subject/actor/scope evidence خودش بسازید. member result oracle نیست. organization باید permission مناسب provider، role معتبر، consent جدید و approval جاری را اثبات کند تا به human publish review برسد.

Verification evidence؛ reviewer چه چیزی را باید بازسازی کند؟

reviewer باید connection id، provider، OIDC subject و authentication state؛ requested/granted scope؛ consent record؛ token expiry/refresh؛ exact approved content؛ publish actor و provider permission؛ provider version/role evidence؛ revocation/reauthorization؛ audit event و provenance را بازسازی کند.

همچنین باید ثابت شود valid sign-in جای missing publish scope را نگرفته، revoke action را متوقف کرده، content mutation approval را invalid کرده، organization publishing از نو محاسبه شده، token secret وارد learner evidence نشده و قبل از side effect provider post ref جعلی ساخته نشده است.

اگر evidence decisive غایب، stale یا متناقض باشد state non-success می‌ماند. verification یعنی evidence قابل‌بازتولید؛ نه اعتماد به hidden reasoning یا badge «Connected».

Assessment و Transfer

S1: boundary MKN-017 و یک non-goal را توضیح دهید. S2: Consented Social Identity & Publishing Contract v1 را برای member baseline بسازید. S3: OIDC session را معتبر نگه دارید ولی publish permission را حذف کنید؛ fieldهای invalid، state و minimal repair را بگویید. S4: member permission را revoke کنید، سپس با organization account و role/scope متفاوت reconnect کنید و تصمیم authority/approval را از evidence جدید بازسازی کنید.

Misconception مسدودکننده: «اگر social sign-in کار می‌کند یا access token وجود دارد، application اجازهٔ post دارد.»

AI می‌تواند evidence synthetic را مرتب و deterministic check اجرا کند. حق invent کردن consent، provider scope، organization role، token validity، content approval، credential واقعی، provider post ref یا permission برای live side effect را ندارد.

منابع، Freshness و مرز Authority

• OpenID Connect Core — FACT: OIDC همچنان authentication layer روی OAuth 2.0 است و identity claim منتقل می‌کند؛ generic publishing authorization نیست.
• RFC 9700 — FACT: OAuth 2.0 Security BCP جاری؛ exact redirect-URI matching و PKCE-related protectionها همچنان current هستند. consent و content approval MAKNOW را تعریف نمی‌کند.
• LinkedIn Posts API — FACT/مثال provider: مستندات فعلی w_member_social، w_organization_social، role constraint سازمانی و version header را نشان می‌دهد. این جزئیات provider-specific و متغیرند.
• MAKNOW design: consent ledger، least privilege، exact content approval، revoke/reauthorize و human publish review authority داخلی است.

Freshness در 2026-09-13 دوباره بررسی شد. بازبینی تا 2027-01-15 یا زودتر در صورت تغییر material در OAuth/OIDC guidance، permissionهای provider، publishing API یا version policy.