OpenID Connect: چیست، پروتکل احراز هویت و مجوزدهی

OpenID Connect چیست؟

OpenID Connect (OIDC) — یک پروتکل باز احراز هویت است که به عنوان لایه‌ای روی OAuth 2.0 ساخته شده است. آنچه را که در OAuth 2.0 کم بود استاندارد می‌کند: تأیید هویت کاربر. اگر OAuth 2.0 به این سؤال پاسخ می‌دهد که «کدام برنامه دسترسی دارد؟»، OIDC به این سؤال پاسخ می‌دهد که «این کاربر دقیقاً کیست؟».

این پروتکل از ID Token — JSON Web Token (JWT) استفاده می‌کند که مجموعه‌ای از claims را شامل می‌شود: شناسه یکتای موضوع، ایمیل، نام، آواتار، زمان‌های صدور و انقضا. برنامه مشتری می‌تواند ID Token را به صورت رمزنگاری تأیید کند — سرور توکن را با RS256 یا ES256 امضا می‌کند و مشتری امضا را با کلید عمومی دریافت شده از طریق JWKS endpoint بررسی می‌کند.

طبق داده‌های Auth0، 2025، بیش از 78٪ از برنامه‌های موبایلی که از احراز هویت شخص ثالث استفاده می‌کنند، OIDC را از طریق Google Sign-In یا Sign in with Apple به کار می‌برند. این پروتکل را به استاندارد دوفاکتو برای ورود اجتماعی و احراز هویت شرکتی تبدیل می‌کند.

OpenID Connect چگونه کار می‌کند

OpenID Connect بسته به نوع مشتری چندین جریان (flow) تعریف می‌کند. برای برنامه‌های موبایل، استاندارد Authorisation Code Flow با Proof Key for Code Exchange (PKCE) است — حتی بدون client secret روی دستگاه محافظت می‌کند.

ارائه‌دهنده هویت و نقش آن

Identity Provider (IdP) — سروری است که احراز هویت کاربر را انجام می‌دهد و توکن‌ها را صادر می‌کند. در اکوسیستم OIDC، IdP دو endpoint کلیدی ارائه می‌دهد: Authorisation Endpoint برای ورود کاربر و Token Endpoint برای تبادل کد با توکن. مشتری آدرس این endpointها را از طریق Discovery URL — مسیر استاندارد /.well-known/openid-configuration که یک سند JSON با تمام پیکربندی ارائه‌دهنده برمی‌گرداند — پیدا می‌کند.

هر IdP JWKS (JSON Web Key Set) خود را منتشر می‌کند — مجموعه کلیدهای عمومی برای تأیید امضای ID Token. مشتری این کلیدها را ذخیره می‌کند و از آنها برای تأیید هر توکن دریافتی بدون مراجعه به سرور استفاده می‌کند.

Authorisation Code Flow با PKCE

Authorisation Code Flow — یک فرایند سه مرحله‌ای است. ابتدا برنامه موبایل یک code verifier (رشته تصادفی به طول ۴۳–۱۲۸ کاراکتر) و hash آن یعنی code challenge تولید می‌کند. برنامه مرورگر یا WebView را با URL حاوی client_id، redirect_uri، scope (openid profile email) و code challenge باز می‌کند. کاربر اطلاعات ورود را در صفحه IdP وارد کرده و رضایت را تأیید می‌کند. IdP مرورگر را با authorisation code به برنامه برمی‌گرداند.

در مرحله دوم، برنامه authorisation code، code verifier و client_id را به Token Endpoint سرور ارسال می‌کند. سرور code verifier را در برابر code challenge ذخیره شده بررسی می‌کند و ID Token، Access Token و به صورت اختیاری Refresh Token را برمی‌گرداند. در مرحله سوم، برنامه ID Token را تأیید می‌کند: امضا را از طریق JWKS تأیید، issuer (iss)، audience (aud) و زمان انقضا (exp) را بررسی می‌کند. اگر تأیید موفق باشد — کاربر احراز هویت شده در نظر گرفته می‌شود.

PKCE (Proof Key for Code Exchange) آسیب‌پذیری ذاتی Authorisation Code Flow استاندارد در مشتریان عمومی را برطرف می‌کند. از آنجا که برنامه موبایل نمی‌تواند client secret را به صورت امن ذخیره کند، مهاجمی که authorisation code را رهگیری کرده می‌توانست آن را با توکن مبادله کند. Code verifier این مشکل را حل می‌کند: حتی اگر کد رهگیری شود، بدون code verifier اصلی تبادل امکان‌پذیر نیست. OAuth Security Best Practices (RFC 9700) برای همه مشتریان عمومی از جمله برنامه‌های موبایل PKCE را الزامی می‌کند.

ID Token و Access Token

OpenID Connect دو توکن اساساً متفاوت برمی‌گرداند: ID Token و Access Token. ID Token — همیشه JWT است که مشتری می‌تواند آن را به طور مستقل بخواند و تأیید کند. این توکن حاوی اطلاعاتی درباره کاربر است و برای احراز هویت استفاده می‌شود، نه برای دسترسی به API.

ساختار ID Token

ID Token از header، payload و signature تشکیل شده که در Base64 کدگذاری شده و با نقطه از هم جدا شده‌اند. Header شامل alg (الگوریتم امضا) و kid (شناسه کلید) است. Payload شامل claims اجباری است: iss (issuer — صادرکننده توکن)، sub (subject — ID یکتای کاربر)، aud (audience — شناسه مشتری)، exp (expiration)، iat (issued at). به صورت اختیاری — name، email، picture، locale.

نمونه payload رمزگشایی شده ID Token از Google:

{
  "iss": "https://accounts.google.com",
  "sub": "1234567890",
  "aud": "my-app-123.apps.googleusercontent.com",
  "exp": 1812345678,
  "iat": 1812342078,
  "name": "ایوان پتروف",
  "email": "ivan@example.com"
}

Access Token — یک opaque token (رشته دلخواه) یا JWT است که مشتری در درخواست‌های API ارسال می‌کند. بر خلاف ID Token، access Token برای خواندن توسط مشتری طراحی نشده است — قالب و محتوای آن فقط برای سرور منابع و سرور مجوزدهی شناخته شده است. Access Token دارای scope — محدودیت حقوق دسترسی — و عمر کوتاه، معمولاً ۱۵–۶۰ دقیقه است.

تفاوت‌های OpenID Connect با OAuth 2.0

OAuth 2.0 — یک چارچوب مجوزدهی است که تعیین می‌کند برنامه چگونه به منابع کاربر دسترسی پیدا می‌کند. OpenID Connect — لایه‌ای است که احراز هویت را به این فرایند اضافه می‌کند. تفاوت کلیدی: OAuth 2.0 قالب توکن را تعیین نمی‌کند و به برنامه راهی برای اینکه بفهمد دقیقاً چه کسی درخواست را انجام داده نمی‌دهد.

چه زمانی OpenID Connect را انتخاب کنیم

OpenID Connect زمانی ضروری است که برنامه نیاز دارد کاربر را بشناسد، نه اینکه فقط به داده‌های او دسترسی داشته باشد. اگر از «ورود با Google» یا «Sign in with Apple» استفاده می‌کنید — این OIDC است. اگر برنامه شما API شخص ثالث را از طرف کاربر بدون نیاز به دانستن هویت او فراخوانی می‌کند — OAuth 2.0 خالص کافی است. برای سیستم‌های شرکتی با Single Sign-On (SSO) انتخاب یک‌طرف است: فقط OpenID Connect، زیرا خروج و مدیریت جلسه استاندارد شده ارائه می‌دهد.

پیاده‌سازی OpenID Connect در برنامه‌های موبایل

ادغام OpenID Connect در برنامه موبایل نیاز به انتخاب کتابخانه مناسب و پیکربندی صحیح جریان دارد. برای Android از credential manager (AndroidX Credentials) یا کتابخانه AppAuth استفاده می‌شود. برای iOS — چارچوب AuthenticationServices با ASWebAuthenticationSession.

نمونه کد در Kotlin (Android)

در زیر نمونه‌ای از اجرای Authorisation Code Flow با استفاده از کتابخانه AppAuth-Android آورده شده است. برنامه یک درخواست مجوزدهی ایجاد می‌کند، مرورگر را برای ورود کاربر باز می‌کند و callback با توکن‌ها را پردازش می‌کند.

val authRequest = AuthorizationRequest.Builder(
    serviceConfig,
    clientId,
    "code",
    Uri.parse("com.example.app:/oauth")
)
.setScope("openid profile email")
.build()

val authService = AuthorizationService(this)
val intent = authService.getAuthorizationRequestIntent(authRequest)
startActivityForResult(intent, REQUEST_CODE)

override fun onActivityResult(
    requestCode: Int,
    resultCode: Int,
    data: Intent?
) {
    if (requestCode == REQUEST_CODE) {
        val response = AuthorizationResponse.fromIntent(data)
        if (response?.authorizationCode != null) {
            exchangeCodeForTokens(response.authorizationCode)
        }
    }
}

نمونه کد در Swift (iOS)

ASWebAuthenticationSession از Apple یک مرورگر داخلی برای جریان OIDC با پشتیبانی SSO از طریق iCloud Keychain ارائه می‌دهد. جلسه با URL مجوزدهی شروع می‌شود و callback از طریق completion handler پردازش می‌شود.

هنگام انتخاب کتابخانه برای OpenID Connect، پشتیبانی از PKCE را به صورت پیش‌فرض در نظر بگیرید: AppAuth-Android و AppAuth-iOS به طور پیش‌فرض از PKCE پشتیبانی می‌کنند. Firebase Authentication در زیرساخت خود برای Google Sign-In، Sign in with Apple و Microsoft از OIDC استفاده می‌کند — توسعه‌دهنده نیازی به پیاده‌سازی دستی جریان ندارد. برای سیستم‌های شرکتی با IdP اختصاصی (مانند Keycloak یا Okta)، AppAuth انتخاب استاندارد با کنترل کامل بر پیکربندی و مدیریت خطا باقی می‌ماند.

let authURL = URL("https://accounts.google.com/o/oauth2/v2/auth")!
let callbackURL = URL("com.example.app://oauth")!

let session = ASWebAuthenticationSession(
    url: authURL,
    callbackURLScheme: callbackURL.scheme!
) { url, error in
    guard let url = url else { return }
    let components = URLComponents(url: url)
    let code = components?.queryItems?.first(where: { $0.name == "code" })?.value
    if let code = code { exchangeCode(code) }
}
session.start()