OpenID Connect در PHP چیست؟ آموزش کامل Login با OAuth 2.0 و OIDC

امروزه بسیاری از سایت‌ها به‌جای اینکه سیستم Login و مدیریت هویت کاربران را کاملاً از صفر پیاده‌سازی کنند، امکان ورود با سرویس‌هایی مانند Google، Microsoft یا سایر Identity Providerها را در اختیار کاربران قرار می‌دهند.

مثلاً کاربر وارد سایت شما می‌شود و روی گزینه:

ورود با Google

کلیک می‌کند.

سپس به Google منتقل می‌شود، Login انجام می‌دهد، اجازه دسترسی را تأیید می‌کند و در نهایت دوباره به سایت شما برمی‌گردد.

اما سایت شما دقیقاً چگونه متوجه می‌شود این کاربر چه کسی است؟

پاسخ این سؤال در بسیاری از این سناریوها OpenID Connect یا OIDC است.

OpenID Connect روی OAuth 2.0 ساخته شده و قابلیت‌های لازم برای Authentication یا احراز هویت کاربر را به OAuth اضافه می‌کند.

در این مقاله از مفاهیم پایه شروع می‌کنیم و سپس ساختار OpenID Connect، ID Token، UserInfo، Authorization Code، PKCE و معماری Login در PHP را بررسی خواهیم کرد.

---

# OpenID Connect چیست؟

OpenID Connect که معمولاً با نام OIDC شناخته می‌شود، یک لایه Identity روی OAuth 2.0 است.

به زبان ساده:

OAuth 2.0

    ↓

Authorization

و:

OpenID Connect

    ↓

Authentication + Identity

به همین دلیل وقتی هدف ما این است که بفهمیم:

> این کاربر چه کسی است؟

OIDC می‌تواند ابزار مناسب‌تری نسبت به OAuth 2.0 خام باشد.

---

# تفاوت OAuth 2.0 و OpenID Connect

این دو مفهوم بسیار نزدیک هستند اما یکی نیستند.

مدل ساده:

OAuth 2.0

    ↓

"این Application چه دسترسی‌ای دارد؟"

در مقابل:

OpenID Connect

    ↓

"این کاربر چه کسی است؟"

---

# چرا OAuth به‌تنهایی برای Login کافی نیست؟

OAuth 2.0 برای Delegated Authorization طراحی شده است.

مثلاً:

Application A

    ↓

می‌خواهد به

Resource B

دسترسی داشته باشد

اما برای Login باید اطلاعات هویتی کاربر را نیز به‌شکل استاندارد دریافت کنیم.

OIDC این لایه را اضافه می‌کند.

مهم‌ترین چیزی که OIDC برای این کار ارائه می‌دهد:

ID Token

است.

---

# ID Token چیست؟

ID Token یک Token است که اطلاعات هویتی مربوط به Authentication را در اختیار Client قرار می‌دهد.

در بسیاری از پیاده‌سازی‌ها ID Token به شکل JWT است.

ساختار کلی:

Header.Payload.Signature

مثلاً Payload ممکن است شامل Claimهایی مانند:

{

    "iss": "https://auth.example.com",

    "sub": "123456789",

    "aud": "my-client",

    "exp": 1750003600,

    "iat": 1750000000

}

البته Claimهای واقعی بسته به Provider و Flow می‌توانند متفاوت باشند.

---

# ID Token با Access Token فرق دارد

این یکی از مهم‌ترین نکات OIDC است.

ID Token

برای Client است تا اطلاعات Authentication و Identity را دریافت و اعتبارسنجی کند.

Access Token

برای دسترسی به Resource Server یا API استفاده می‌شود.

بنابراین نباید این دو را جایگزین یکدیگر کنیم.

مدل:

ID Token

    ↓

Who is the user?

و:

Access Token

    ↓

What can the Client access?

---

# Scope در OpenID Connect

در OIDC، مهم‌ترین Scope:

openid

است.

برای مثال:

scope=openid profile email

یعنی Client علاوه بر فعال کردن OIDC، اطلاعات مربوط به Profile و Email را نیز درخواست می‌کند.

Scopeهای متداول:

openid

profile

email

address

phone

---

# Identity Provider چیست؟

Identity Provider یا IdP سرویسی است که هویت کاربر را مدیریت می‌کند.

مثلاً:

User

 ↓

Identity Provider

 ↓

Authentication

 ↓

Identity Information

در یک معماری واقعی ممکن است Identity Provider شامل:

Login

Password

2FA

MFA

Session

Consent

Token

User Profile

باشد.

---

# مثال ساده

فرض کنید سایت ما:

cmsnevis.ir

باشد.

کاربر می‌خواهد با حساب یک Identity Provider وارد سایت شود.

مدل کلی:

User

 ↓

CMSNevis

 ↓

Identity Provider

 ↓

Login

 ↓

Consent

 ↓

Authorization Code

 ↓

CMSNevis

 ↓

Token Endpoint

 ↓

ID Token + Access Token

سپس سایت ما User را در دیتابیس خودش پیدا یا ایجاد می‌کند.

---

# OIDC Discovery چیست؟

یکی از قابلیت‌های بسیار مهم OpenID Connect، Discovery است.

Identity Provider می‌تواند اطلاعات مربوط به Endpointهای خودش را در یک Document استاندارد منتشر کند.

معمولاً مسیر معروف:

.well-known/openid-configuration

است.

مثلاً:

https://auth.example.com/.well-known/openid-configuration

این Document می‌تواند اطلاعاتی مانند موارد زیر را مشخص کند:

{

    "issuer": "https://auth.example.com",

    "authorization_endpoint": "https://auth.example.com/authorize",

    "token_endpoint": "https://auth.example.com/token",

    "userinfo_endpoint": "https://auth.example.com/userinfo",

    "jwks_uri": "https://auth.example.com/jwks"

}

---

# چرا Discovery مهم است؟

بدون Discovery ممکن است مجبور شویم Endpointهای Provider را به‌صورت دستی در Application تعریف کنیم.

اما با Discovery، Application می‌تواند اطلاعات استاندارد Provider را دریافت کند.

البته باید:

• HTTPS استفاده شود
• issuer اعتبارسنجی شود
• Metadata از منبع معتبر دریافت شود
• تغییرات Provider مدیریت شود

---

# Authorization Endpoint

اولین مرحله Login معمولاً انتقال User به Authorization Endpoint است.

مثلاً:

https://auth.example.com/authorize

پارامترهای مهم:

client_id

redirect_uri

response_type

scope

state

nonce

code_challenge

code_challenge_method

برای OIDC:

response_type=code

و:

scope=openid

اهمیت ویژه‌ای دارند.

---

# state در OIDC

state برای ارتباط دادن Authorization Response با Session/Request اولیه استفاده می‌شود و در برابر حملات CSRF در Flow نقش مهمی دارد.

در PHP:

$state = bin2hex(random_bytes(32));



$_SESSION['oidc_state'] = $state;

سپس:

state=generated_random_value

ارسال می‌شود.

بعد از برگشت:

$receivedState = $_GET['state'] ?? '';



if (

    !hash_equals(

        $_SESSION['oidc_state'] ?? '',

        $receivedState

    )

) {

    http_response_code(400);

    exit('Invalid state');

}

---

# nonce چیست؟

nonce یکی دیگر از پارامترهای مهم OIDC است.

Nonce برای ارتباط دادن Authentication Request با ID Token و کمک به جلوگیری از Replay در این زمینه استفاده می‌شود.

در PHP:

$nonce = bin2hex(random_bytes(32));



$_SESSION['oidc_nonce'] = $nonce;

و در Authorization Request:

nonce=generated_random_value

قرار می‌گیرد.

بعد از دریافت ID Token باید Claim مربوط به nonce بررسی شود.

مثلاً:

if (!hash_equals(

    $_SESSION['oidc_nonce'] ?? '',

    $claims['nonce'] ?? ''

)) {

    throw new RuntimeException(

        'Invalid nonce'

    );

}

---

# Authorization Code Flow در OIDC

برای بسیاری از Applicationهای جدید، Flow اصلی چنین است:

User

 ↓

Client

 ↓

Authorization Endpoint

 ↓

Login

 ↓

Consent

 ↓

Authorization Code

 ↓

Client

 ↓

Token Endpoint

 ↓

ID Token + Access Token

اگر Client یک Public Client باشد، معمولاً PKCE نیز اضافه می‌شود.

---

# PKCE در OIDC

PKCE برای محافظت از Authorization Code Flow استفاده می‌شود.

ابتدا:

code_verifier

ساخته می‌شود.

سپس:

code_challenge = SHA256(code_verifier)

محاسبه می‌شود.

در درخواست Authorization:

code_challenge

code_challenge_method=S256

ارسال می‌شود.

در Token Exchange:

code_verifier

ارسال می‌شود.

---

# ساخت PKCE در PHP

یک نمونه ساده:

$codeVerifier = rtrim(

    strtr(

        base64_encode(

            random_bytes(32)

        ),

        '+/',

        '-_'

    ),

    '='

);



$codeChallenge = rtrim(

    strtr(

        base64_encode(

            hash(

                'sha256',

                $codeVerifier,

                true

            )

        ),

        '+/',

        '-_'

    ),

    '='

);

مقدار codeVerifier را باید در Session یا Storage امن مربوط به Flow نگه داشت.

---

# دریافت Authorization Code

بعد از Login کاربر ممکن است به این آدرس برگردد:

https://example.com/oidc/callback?code=abc123&state=xyz

در PHP:

$code = $_GET['code'] ?? '';

$state = $_GET['state'] ?? '';

ابتدا State را بررسی می‌کنیم.

بعد Code را به Token Endpoint ارسال می‌کنیم.

---

# Token Endpoint

Client درخواست زیر را ارسال می‌کند:

POST /token

Content-Type: application/x-www-form-urlencoded

مثلاً:

grant_type=authorization_code

code=abc123

redirect_uri=https://example.com/oidc/callback

client_id=my-client

code_verifier=...

در صورت موفقیت، Provider ممکن است پاسخی مانند این برگرداند:

{

    "access_token": "ACCESS_TOKEN",

    "token_type": "Bearer",

    "expires_in": 3600,

    "id_token": "JWT_ID_TOKEN"

}

ممکن است Refresh Token نیز وجود داشته باشد.

---

# ID Token را چگونه اعتبارسنجی کنیم؟

یکی از اشتباهات بسیار خطرناک این است که فقط Payload JWT را Decode کنیم و به آن اعتماد کنیم.

این کافی نیست.

باید مواردی مانند:

Signature

Issuer

Audience

Expiration

Issued At

Nonce

بررسی شوند.

---

# Signature Verification

فرض کنید ID Token یک JWT است.

ساختار:

HEADER.PAYLOAD.SIGNATURE

ما باید Signature را با کلید عمومی Provider بررسی کنیم.

Provider معمولاً کلیدهای عمومی خود را از طریق:

jwks_uri

معرفی می‌کند.

---

# JWKS چیست؟

JWKS مخفف JSON Web Key Set است.

یک Endpoint که کلیدهای عمومی مورد نیاز برای اعتبارسنجی Signature را ارائه می‌کند.

مثلاً:

https://auth.example.com/.well-known/jwks.json

ممکن است شامل چند کلید باشد.

Client باید بر اساس kid موجود در JWT، کلید مناسب را پیدا کند.

---

# فقط Decode کردن JWT کافی نیست

این کار:

$payload = json_decode(

    base64_decode($parts[1]),

    true

);

به‌تنهایی اعتبارسنجی محسوب نمی‌شود.

مهاجم می‌تواند Payload دلخواه خودش را ایجاد کند.

بنابراین باید:

JWT

 ↓

Parse

 ↓

Signature Verification

 ↓

Issuer Validation

 ↓

Audience Validation

 ↓

Expiration Validation

 ↓

Nonce Validation

انجام شود.

---

# Issuer چیست؟

Claim:

iss

مشخص می‌کند Token توسط چه صادرکننده‌ای ایجاد شده است.

مثلاً:

{

    "iss": "https://auth.example.com"

}

Client باید بررسی کند که Issuer همان Provider مورد انتظار باشد.

---

# Audience چیست؟

Claim:

aud

مشخص می‌کند Token برای چه Clientای صادر شده است.

اگر Client شما:

my-client-123

باشد، باید بررسی کنید:

aud = my-client-123

و صرفاً به معتبر بودن Signature اکتفا نکنید.

---

# Expiration چیست؟

Claim:

exp

زمان انقضای Token را مشخص می‌کند.

اگر:

exp < current_time

باشد، Token نباید پذیرفته شود.

---

# Subject چیست؟

Claim:

sub

شناسه یکتای User در Identity Provider است.

مثلاً:

{

    "sub": "00u123456789"

}

این مقدار برای شناسایی کاربر در Provider بسیار مهم است.

---

# آیا Email برای شناسایی User مناسب است؟

در بسیاری از سیستم‌ها بهتر است شناسه اصلی کاربر خارجی را بر اساس:

issuer + subject

در نظر بگیریم.

مثلاً:

provider_issuer

+

sub

چرا؟

چون Email ممکن است تغییر کند.

اما شناسه Subject در همان Provider برای User معمولاً شناسه پایدارتر و مناسب‌تری برای اتصال Identity است.

---

# UserInfo Endpoint چیست؟

OIDC یک Endpoint استاندارد برای دریافت اطلاعات User نیز دارد:

/userinfo

Client Access Token را ارسال می‌کند:

Authorization: Bearer ACCESS_TOKEN

و UserInfo Server اطلاعات هویتی مورد مجاز را برمی‌گرداند.

مثلاً:

{

    "sub": "123456",

    "name": "Ali",

    "email": "ali@example.com"

}

---

# ID Token یا UserInfo؟

این دو را نباید یکی در نظر بگیریم.

ID Token اطلاعات Authentication را به Client می‌دهد.

UserInfo Endpoint اطلاعات User را از Resource Server دریافت می‌کند.

بسته به Provider و Scopeها، اطلاعات موجود در هرکدام می‌تواند متفاوت باشد.

---

# Scopeهای profile و email

اگر Client درخواست کند:

scope=openid profile email

ممکن است اطلاعاتی مانند:

name

family_name

given_name

picture

email

email_verified

دریافت کند.

اما مقدار واقعی Claimها به Provider و مجوزهای اعطاشده بستگی دارد.

---

# email_verified چیست؟

وجود Email به‌تنهایی به این معنی نیست که Email توسط Provider تأیید شده است.

در برخی Providerها Claim زیر وجود دارد:

{

    "email": "user@example.com",

    "email_verified": true

}

اگر Application نیاز دارد Email را به‌عنوان یک هویت تأییدشده قبول کند، باید وضعیت email_verified را مطابق سیاست امنیتی خودش بررسی کند.

---

# اتصال User خارجی به User داخلی

فرض کنیم در دیتابیس خودمان جدول:

users

داریم.

و می‌خواهیم User OIDC را به User داخلی متصل کنیم.

بهتر است جدولی مانند:

user_identities

داشته باشیم.

مثلاً:

user_id

provider

issuer

subject

created_at

updated_at

نمونه:

user_id = 25

provider = google

issuer = https://accounts.example.com

subject = 123456789

---

# چرا جدول Identity جداگانه بهتر است؟

چون یک User می‌تواند چند Identity داشته باشد.

مثلاً:

User 25

 ├── Google

 ├── Microsoft

 └── GitHub

مدل:

users

   │

   └── user_identities

           ├── google

           ├── microsoft

           └── github

به سیستم انعطاف بیشتری می‌دهد.

---

# مثال ساده Login در PHP

فرض کنیم بعد از اعتبارسنجی ID Token به این اطلاعات رسیده‌ایم:

$issuer = $claims['iss'];

$subject = $claims['sub'];

ابتدا Identity را پیدا می‌کنیم:

$stmt = $pdo->prepare(

    'SELECT user_id

     FROM user_identities

     WHERE issuer = :issuer

       AND subject = :subject

     LIMIT 1'

);



$stmt->execute([

    'issuer' => $issuer,

    'subject' => $subject,

]);



$identity = $stmt->fetch(PDO::FETCH_ASSOC);

اگر وجود داشت:

$userId = $identity['user_id'];

و اگر وجود نداشت، می‌توان طبق سیاست Application کاربر جدید ایجاد کرد.

---

# ایجاد User جدید

مثلاً:

$pdo->beginTransaction();



try {

    $stmt = $pdo->prepare(

        'INSERT INTO users (name, email)

         VALUES (:name, :email)'

    );



    $stmt->execute([

        'name' => $claims['name'] ?? null,

        'email' => $claims['email'] ?? null,

    ]);



    $userId = (int) $pdo->lastInsertId();



    $stmt = $pdo->prepare(

        'INSERT INTO user_identities

         (user_id, issuer, subject)

         VALUES (:user_id, :issuer, :subject)'

    );



    $stmt->execute([

        'user_id' => $userId,

        'issuer' => $issuer,

        'subject' => $subject,

    ]);



    $pdo->commit();



} catch (Throwable $e) {

    $pdo->rollBack();

    throw $e;

}

در Production باید Validation، Unique Constraint و Error Handling مناسب نیز وجود داشته باشد.

---

# Unique Constraint بسیار مهم است

روی Identity بهتر است Constraint مناسب داشته باشیم.

مثلاً:

UNIQUE (issuer, subject)

این کار کمک می‌کند یک Identity یکسان به چند User داخلی متصل نشود.

---

# بعد از Login چه اتفاقی می‌افتد؟

OIDC خودش الزام نمی‌کند که Session سایت شما چگونه مدیریت شود.

بعد از اینکه Identity Provider کاربر را تأیید کرد، Application می‌تواند Session داخلی خودش را ایجاد کند.

مثلاً:

session_regenerate_id(true);



$_SESSION['user_id'] = $userId;

در این حالت:

OIDC

 ↓

Identity Verification

 ↓

Local User

 ↓

Local Session

داریم.

این معماری در بسیاری از سایت‌های Server-rendered مناسب است.

---

# Logout در OIDC

Logout در سیستم‌های OIDC می‌تواند چند بخش داشته باشد:

Local Session

Provider Session

Access Token

Refresh Token

اگر فقط Session داخلی را حذف کنیم:

$_SESSION = [];



session_destroy();

کاربر از سایت ما خارج می‌شود، اما ممکن است Session او در Identity Provider همچنان فعال باشد.

برخی Providerها قابلیت RP-Initiated Logout یا مکانیزم‌های مشابه را ارائه می‌کنند.

جزئیات دقیق به Provider بستگی دارد.

---

# Single Sign-On چیست؟

یکی از مزایای Identity Provider این است که می‌تواند SSO ارائه دهد.

مثلاً:

Identity Provider

       │

 ┌─────┼─────┐

 ▼     ▼     ▼

Site A Site B Site C

کاربر یک بار در Identity Provider Login می‌کند و Applicationهای مختلف می‌توانند بر اساس سیاست‌های خود از همان Identity استفاده کنند.

---

# OIDC و Single Sign-On

در یک معماری SSO:

User

 ↓

Identity Provider

 ↓

Authentication

 ↓

Application A

Application B

Application C

هر Application می‌تواند Client جداگانه‌ای داشته باشد.

این مدل در سیستم‌های سازمانی و چند Application بسیار کاربردی است.

---

# امنیت OpenID Connect

برای ساخت Login امن با OIDC باید موارد زیر جدی گرفته شوند:

HTTPS

State

Nonce

PKCE

Redirect URI Validation

Issuer Validation

Audience Validation

Signature Verification

Expiration

Token Storage

Session Security

CSRF Protection

Rate Limiting

---

# اشتباهات رایج در OIDC

1. اعتماد به Payload بدون بررسی Signature

Decode کردن JWT به معنی معتبر بودن آن نیست.

---

2. بررسی نکردن Issuer

ممکن است Token از صادرکننده‌ای غیر از Provider مورد انتظار آمده باشد.

---

3. بررسی نکردن Audience

Token باید برای Client موردنظر صادر شده باشد.

---

4. بررسی نکردن Nonce

Nonce بخشی از امنیت OIDC Flow است.

---

5. عدم استفاده از State

State باید برای جلوگیری از مشکلات مربوط به Authorization Request بررسی شود.

---

6. استفاده نکردن از PKCE برای Public Client

برای SPA و Mobile App، PKCE اهمیت ویژه‌ای دارد.

---

7. استفاده از Email به‌عنوان تنها شناسه خارجی

بهتر است Identity بر اساس issuer + subject مدیریت شود.

---

8. قرار دادن Client Secret در JavaScript

Public Client نمی‌تواند Secret را مانند Backend محرمانه نگه دارد.

---

9. نگهداری Access Token در URL

Token نباید در Query String قرار گیرد.

---

10. اشتباه گرفتن ID Token و Access Token

هرکدام هدف متفاوتی دارند.

---

# معماری کامل Login با OIDC

یک معماری استاندارد را می‌توان این‌گونه خلاصه کرد:

                 User

                   │

                   ▼

             Your Website

                   │

                   ▼

        Authorization Request

                   │

        state + nonce + PKCE

                   │

                   ▼

          Identity Provider

                   │

              Login/Consent

                   │

                   ▼

         Authorization Code

                   │

                   ▼

           Your Backend

                   │

                   ▼

            Token Endpoint

                   │

          ┌────────┴────────┐

          ▼                 ▼

      ID Token         Access Token

          │                 │

          ▼                 ▼

    Verify Identity    API Access

          │

          ▼

      Local User

          │

          ▼

    Local Session

---

# نمونه Endpointهای OIDC

در یک Provider استاندارد ممکن است Endpointهای زیر را ببینیم:

/.well-known/openid-configuration

/authorize

/token

/userinfo

/jwks

بسته به Provider ممکن است نام یا ساختار URLها متفاوت باشد.

بنابراین بهتر است Endpointها را از Discovery Metadata دریافت کنیم، نه اینکه بدون بررسی آن‌ها را Hard-Code کنیم.

---

# OIDC و APIهای مدرن

OIDC می‌تواند در معماری‌هایی مانند این استفاده شود:

Frontend

   ↓

OIDC Provider

   ↓

Access Token

   ↓

API

در این معماری:

OIDC

مسئول Identity است و:

Access Token

برای دسترسی به API استفاده می‌شود.

اما API همچنان باید Authorization خودش را انجام دهد.

یعنی:

Valid Token

به‌تنهایی به معنی:

Full Access

نیست.

---

# OIDC و Role/Permission

فرض کنیم User با موفقیت Login کرده است.

اطلاعات هویتی:

User ID = 25

اما API باید بررسی کند:

Can User 25 access this resource?

بنابراین:

Authentication

+

Authorization

هر دو مورد نیاز هستند.

---

# آیا باید اطلاعات Role را داخل ID Token قرار دهیم؟

ممکن است بعضی Providerها Claimهایی مانند:

roles

groups

permissions

را ارائه کنند.

اما Application نباید صرفاً به وجود یک Claim اعتماد کند.

باید بررسی شود که:

• Token معتبر است
• Issuer درست است
• Audience درست است
• Claim معتبر است
• سیاست Authorization سیستم اجازه این دسترسی را می‌دهد

---

# استفاده از Library در PHP

برای اعتبارسنجی کامل OIDC بهتر است در Production از Libraryهای معتبر استفاده شود.

چرا؟

چون پیاده‌سازی دستی مواردی مانند:

JWT Signature

JWKS

Key Rotation

Algorithm Validation

Claim Validation

PKCE

می‌تواند پیچیده و حساس باشد.

در پیاده‌سازی واقعی باید کتابخانه‌ای انتخاب شود که استانداردهای OIDC و JWT را به‌درستی پیاده کند و به‌روز نگه داشته شود.

---

# یک چک‌لیست نهایی OIDC

قبل از Production:

[ ] HTTPS فعال است

[ ] Discovery Metadata اعتبارسنجی می‌شود

[ ] Issuer بررسی می‌شود

[ ] Audience بررسی می‌شود

[ ] Signature ID Token بررسی می‌شود

[ ] Expiration بررسی می‌شود

[ ] Nonce بررسی می‌شود

[ ] State بررسی می‌شود

[ ] PKCE برای Public Client فعال است

[ ] Redirect URI محدود است

[ ] Client Secret در Backend نگهداری می‌شود

[ ] Access Token در URL قرار نمی‌گیرد

[ ] Tokenها در Log ثبت نمی‌شوند

[ ] User بر اساس issuer + subject شناسایی می‌شود

[ ] Unique Constraint برای Identity وجود دارد

[ ] Session بعد از Login ایمن ایجاد می‌شود

[ ] Authorization جداگانه انجام می‌شود

[ ] Rate Limiting وجود دارد

[ ] Logout به‌درستی طراحی شده است

---

# جمع‌بندی

OpenID Connect یکی از مهم‌ترین استانداردهای مدرن برای پیاده‌سازی Authentication روی OAuth 2.0 است.

اگر بخواهیم تفاوت را خیلی ساده بیان کنیم:

OAuth 2.0

    ↓

Authorization

و:

OpenID Connect

    ↓

Authentication + Identity

در یک Login مدرن با OIDC، معمولاً چنین مسیری داریم:

User

 ↓

Authorization Server

 ↓

Login

 ↓

Authorization Code

 ↓

PKCE

 ↓

Token Endpoint

 ↓

ID Token

 ↓

Validation

 ↓

Find/Create Local User

 ↓

Local Session

مهم‌ترین نکته امنیتی این است که نباید صرفاً Payload یک ID Token را Decode کنیم و به آن اعتماد کنیم.

Signature، Issuer، Audience، Expiration، Nonce و سایر پارامترهای لازم باید طبق Flow و مشخصات Provider اعتبارسنجی شوند.

همچنین issuer + subject معمولاً مبنای مناسبی برای اتصال Identity خارجی به User داخلی است و Email نباید تنها شناسه خارجی User در نظر گرفته شود.

در نهایت، OIDC جایگزین Authorization داخلی Application نیست. حتی پس از Login موفق، سیستم شما باید همچنان Permission، Role و مالکیت Resourceها را بررسی کند.

---

# سوالات متداول

OpenID Connect چیست؟

OpenID Connect یک لایه Identity روی OAuth 2.0 است که امکانات استانداردی برای Authentication و دریافت اطلاعات هویتی User فراهم می‌کند.

آیا OIDC همان OAuth 2.0 است؟

خیر. OIDC روی OAuth 2.0 ساخته شده و قابلیت‌های مربوط به Identity و Authentication را اضافه می‌کند.

ID Token چیست؟

ID Token اطلاعات مربوط به Authentication و Identity کاربر را در اختیار Client قرار می‌دهد و معمولاً به شکل JWT است.

Access Token و ID Token چه تفاوتی دارند؟

ID Token برای اطلاعات هویتی Authentication است، درحالی‌که Access Token برای دسترسی به Resource Server استفاده می‌شود.

nonce در OIDC چیست؟

Nonce یک مقدار تصادفی است که برای ارتباط دادن Authentication Request با ID Token و کاهش خطر Replay در این Flow استفاده می‌شود.

state در OIDC چیست؟

State برای ارتباط دادن Request اولیه با Response برگشتی و محافظت در برابر مشکلات CSRF در Authorization Flow استفاده می‌شود.

آیا برای OIDC به JWT نیاز داریم؟

ID Token در OIDC معمولاً JWT است، اما JWT و OIDC دو مفهوم یکسان نیستند.

آیا OIDC برای ورود با Google استفاده می‌شود؟

بله، سرویس‌هایی مانند Google می‌توانند از OpenID Connect برای Authentication استفاده کنند.

آیا می‌توان OIDC را بدون HTTPS استفاده کرد؟

برای Production نباید ارتباطات حساس OIDC را بدون HTTPS طراحی کرد.

---

# مقاله بعدی

بعد از این مقاله، مسیر بسیار خوبی برای ادامه کلاستر این است:

«OAuth 2.0 و OpenID Connect در PHP با Google؛ آموزش عملی Login با Google از صفر تا Production»

در آن مقاله از حالت مفهومی خارج می‌شویم و یک پروژه PHP واقعی را مرحله‌به‌مرحله می‌سازیم؛ از ساخت OAuth Client و Redirect URI تا Authorization Code، PKCE، دریافت ID Token، اعتبارسنجی Token، ساخت User داخلی و ایجاد Session.