OAuth 2.0 ve OIDC nedir, nedir değildir?
OAuth 2.0 bir authorization framework — bir uygulamanın kullanıcı adına başka bir servise erişim yetkisi alma protokolü. OIDC (OpenID Connect) OAuth 2.0 üzerine bir identity layer ekler — kullanıcının kim olduğunu doğrular. İkisi sıkça karıştırılır ama farklı:- OAuth 2.0 — "Bu uygulamaya benim adıma X yapma izni veriyorum."
- OIDC — "Bu kullanıcı X kişidir, doğrulandı."
AIOR projelerinde kurumsal SSO entegrasyonları için OIDC tercih ediliyor; üçüncü taraf API erişimi için OAuth 2.0 kullanılıyor.
Akış tipleri ve seçim
- Authorization Code (with PKCE) — web uygulamaları, mobile apps, SPA'lar için varsayılan. AIOR'ın standart önerisi.
- Client Credentials — server-to-server, kullanıcı yok. API key alternatifi.
- Device Code — TV, IoT cihazlar gibi sınırlı UI'ı olan cihazlar.
- Refresh Token — uzun ömürlü token yenileme.
2026'da artık DEPRECATED olan akışlar:
- Implicit Flow — güvenlik açıkları nedeniyle. PKCE ile Authorization Code kullanın.
- Resource Owner Password Credentials — uygulamanın kullanıcı şifresini görmesi yasaktır.
PKCE — neden zorunlu hâle geldi
PKCE (Proof Key for Code Exchange) authorization code interception saldırılarına karşı koruma. 2020 sonrası tüm public client'lar (SPA, mobile) için zorunlu. 2026'da confidential client'lar (server-side web app) için de önerilir.Akış: client `code_verifier` üretir, `code_challenge` (SHA256 hash) ile authorization isteğine ekler. Token exchange sırasında `code_verifier`'i yine gönderir; server eşleşmeyi doğrular.
AIOR'da OAuth client implementasyonlarında PKCE her zaman aktif.
JWT — access token ve identity token formatı
OAuth 2.0 spec token format zorunlu kılmaz; JWT en yaygın tercih. AIOR projelerinde JWT validation disiplini:- `iss` (issuer) — token'ı veren authority doğrulanır.
- `aud` (audience) — token'ın hedeflendiği API/client doğrulanır.
- `exp` (expiration) — süre dolmuş token reddedilir.
- `nbf` (not before) — geçerlilik başlangıcı kontrol edilir.
- Signature verification — public key (RS256) veya shared secret (HS256) ile.
- `jti` (JWT ID) — replay attack koruması için kullanılabilir.
JWT secrets veya signing keys güvenli saklanmalı — environment variable veya secret manager (HashiCorp Vault, AWS Secrets Manager).
Token storage — frontend tarafında
SPA/mobile uygulamalarda access token nereye saklanır?- localStorage — XSS'e açık, kötü öneri.
- sessionStorage — aynı problem.
- HttpOnly Cookie — XSS-safe, CSRF protection gerektirir. AIOR'ın tercihi.
- Memory (variable) — sayfa yenilemede kaybolur; refresh token ile yeniden alınır.
Identity provider tercihi
AIOR projelerinde sıkça kullandığımız IDP'ler:- Keycloak — açık kaynak, self-hosted, geniş özellik seti. AIOR'ın varsayılan tercihi.
- Auth0 — managed service, geniş entegrasyonlar.
- AWS Cognito — AWS ekosisteminde mantıklı.
- Okta — enterprise SSO.
- Azure AD / Microsoft Entra ID — Microsoft ekosistemi.
Self-hosted Keycloak Frankfurt veri merkezinde çalıştırdığımız müşteri projelerinde standardımız — veri lokasyonu garantisi ve maliyet kontrolü.
Single Sign-On (SSO) entegrasyonları
Kurumsal SSO için OIDC veya SAML 2.0. Modern entegrasyonlarda OIDC tercih — JSON-based, mobile-friendly, geliştirme deneyimi daha iyi. SAML hâlâ legacy enterprise SSO'larda zorunlu.AIOR projelerinde Azure AD/Entra ID, Google Workspace, ADFS, Okta entegrasyonları sıkça uygulanıyor.
MFA (Multi-Factor Authentication)
2026'da MFA artık opsiyonel değil. AIOR projelerinde standart MFA seçenekleri:- TOTP (Authenticator app — Google Authenticator, Authy).
- Passkey / WebAuthn — passwordless, FIDO2 tabanlı. Modern standart.
- SMS (legacy, SIM swap riski nedeniyle önerilmiyor).
- Push notification (kurumsal uygulamalarda).
Passkey desteği 2026'da yaygın; AIOR projelerinde yeni başlangıçlarda passkey öncelikli MFA.
Yaygın güvenlik hataları
- State parameter eksikliği — CSRF açığı.
- Redirect URI whitelist eksik — open redirect saldırısı.
- Token revocation eksik — logout sonrası token hâlâ geçerli.
- JWT'de hassas veri — token Base64, encrypted değil; PII koymayın.
- Refresh token rotation eksik — token theft sonrası uzun süreli erişim.
Sonuç
OAuth 2.0 ve OIDC 2026'da modern kimlik doğrulamanın standartları. Doğru akış seçimi, PKCE disiplini, MFA + Passkey desteği, ve sıkı token yönetimi ile güvenli authentication kurulabilir. AIOR olarak müşteri projelerinde Keycloak + OIDC + Passkey kombinasyonunu standart paket olarak teslim ediyoruz. Sizin tarafınızda OAuth/OIDC implementasyonunda en sık karşılaştığınız sorun ne — refresh token rotation, MFA kullanıcı deneyimi, yoksa SSO mapping mi?What OAuth 2.0 and OIDC are — and aren't
OAuth 2.0 is an authorization framework — a protocol for an application to obtain delegated access to another service on a user's behalf. OIDC (OpenID Connect) adds an identity layer on top of OAuth 2.0 — verifying who the user is. They're often confused but they're different:- OAuth 2.0 — "I grant this app permission to do X on my behalf."
- OIDC — "This user is person X, verified."
For enterprise SSO integrations on AIOR projects, OIDC is preferred; OAuth 2.0 is used for third-party API access.
Flow types and selection
- Authorization Code (with PKCE) — default for web apps, mobile apps, SPAs. AIOR's standard recommendation.
- Client Credentials — server-to-server, no user. Alternative to API key.
- Device Code — for devices with limited UI like TVs, IoT.
- Refresh Token — long-lived token renewal.
Flows now DEPRECATED in 2026:
- Implicit Flow — due to security holes. Use Authorization Code with PKCE.
- Resource Owner Password Credentials — apps must not see the user's password.
PKCE — why it became mandatory
PKCE (Proof Key for Code Exchange) protects against authorization code interception attacks. Since 2020 it's mandatory for all public clients (SPA, mobile). In 2026 it's also recommended for confidential clients (server-side web apps).Flow: the client generates a `code_verifier`, attaches a `code_challenge` (SHA256 hash) to the authorization request. During token exchange, it sends the `code_verifier`; the server verifies the match.
PKCE is always on in AIOR OAuth client implementations.
JWT — access token and identity token format
The OAuth 2.0 spec doesn't mandate a token format; JWT is the most common choice. JWT validation discipline on AIOR projects:- `iss` (issuer) — verify the token's issuing authority.
- `aud` (audience) — verify the token's intended API/client.
- `exp` (expiration) — reject expired tokens.
- `nbf` (not before) — check validity start.
- Signature verification — via public key (RS256) or shared secret (HS256).
- `jti` (JWT ID) — usable for replay attack protection.
JWT secrets or signing keys must be stored securely — environment variables or a secret manager (HashiCorp Vault, AWS Secrets Manager).
Token storage on the frontend
Where to store access tokens in SPA/mobile apps?- localStorage — XSS-exposed, bad advice.
- sessionStorage — same problem.
- HttpOnly Cookie — XSS-safe, needs CSRF protection. AIOR's pick.
- Memory (variable) — lost on page reload; restored via refresh token.
Identity provider choice
IDPs we use often on AIOR projects:- Keycloak — open source, self-hosted, broad feature set. AIOR's default.
- Auth0 — managed service, broad integrations.
- AWS Cognito — sensible inside the AWS ecosystem.
- Okta — enterprise SSO.
- Azure AD / Microsoft Entra ID — Microsoft ecosystem.
Self-hosted Keycloak running in the Frankfurt data centre is our standard on customer projects — data locality guarantees and cost control.
Single Sign-On (SSO) integrations
For enterprise SSO, OIDC or SAML 2.0. Modern integrations prefer OIDC — JSON-based, mobile-friendly, better developer experience. SAML is still mandatory in legacy enterprise SSO.Azure AD/Entra ID, Google Workspace, ADFS, Okta integrations are frequently applied on AIOR projects.
MFA (Multi-Factor Authentication)
MFA is no longer optional in 2026. Standard MFA options on AIOR projects:- TOTP (Authenticator app — Google Authenticator, Authy).
- Passkey / WebAuthn — passwordless, FIDO2-based. The modern standard.
- SMS (legacy, not recommended due to SIM swap risk).
- Push notifications (in enterprise apps).
Passkey support is widespread in 2026; on new starts at AIOR, passkey is the primary MFA.
Common security mistakes
- Missing state parameter — CSRF vulnerability.
- Missing redirect URI whitelist — open redirect attack.
- Missing token revocation — token still valid after logout.
- Sensitive data in JWT — token is Base64, not encrypted; don't put PII.
- Missing refresh token rotation — long-term access after token theft.
