Hacker DirectoryHacker Directory
Öğrenmeye devam et
ENHTML kaydet ↓

WEB / WEB-14.02

Basic authentication, API key ve bearer token

Basic bir HTTP authentication scheme; API key bir application credential tasarımı; bearer ise possession semantics’tir. Aynı request içinde görünmeleri aynı identity veya permission anlamına gelmez.

CORE · RED · BLUE · ARTIFACT · PRACTICE

1. Core · Mekanizma

Hareket olmadan bütün senaryoları oku

Bearer · user grant

  1. Bearer alias hazır

    Client protected own-note action’ı için bearer alias seçer; gerçek credential gösterilmez.

    Client
    bearer-duru-read alias
    Atlas API
    No request
    Trusted registry/policy
    User grant: Duru; Atlas API; read own note
  2. Bearer request ulaştı

    HTTPS request Bearer scheme’i taşır. Parsing henüz validity veya permission değildir.

    Client
    Waiting
    Atlas API
    Received Bearer alias; unresolved
    Trusted registry/policy
    User grant: Duru; Atlas API; read own note
  3. Registry binding çözülür

    Bu local fixture valid credential, subject ve audience’ı çözer; remote introspection çizilmez.

    Client
    Waiting
    Atlas API
    Valid: subject-duru; audience Atlas API
    Trusted registry/policy
    Active grant; required scope present
  4. Action policy geçer

    Own-note relationship ve read permission supplied allowed’dur.

    Client
    Waiting
    Atlas API
    ALLOW own note
    Trusted registry/policy
    Valid grant + resource policy passed
  5. Representation ulaştı

    Client yalnız bu action için izinli representation alır.

    Client
    Own note delivered
    Atlas API
    Response: allowed
    Trusted registry/policy
    Valid grant + resource policy passed

App key · deny

  1. Application key alias’ı

    Key public cover application’ı için tanımlıdır. Request private note ister.

    Client
    key-cover-app; private-note request
    Atlas API
    No request
    Trusted registry/policy
    Application attribution; no user subject
  2. Key taşıyan request ulaştı

    X-Atlas-Key bu fixture’ın product contract’ıdır; standard HTTP scheme iddiası yok.

    Client
    Waiting
    Atlas API
    Received application key alias
    Trusted registry/policy
    Application attribution; no user subject
  3. Key tanındı, user çözülmedi

    Registry application binding’ini döndürür. Duru subject’i üretilmez.

    Client
    Waiting
    Atlas API
    Key valid; user subject absent
    Trusted registry/policy
    Purpose: public cover fetch only
  4. Private action reddedilir

    Private-note policy user/resource authority gerektirir; key attribution bunu sağlamaz.

    Client
    Waiting
    Atlas API
    DENY private-note action
    Trusted registry/policy
    Application attribution remains; no permission elevation
  5. Denial ulaştı

    Key’in tanınması ile private representation’ın verilmesi arasındaki sınır korunur.

    Client
    No private representation
    Atlas API
    Response: action denied
    Trusted registry/policy
    Application attribution remains; no permission elevation

Basic · mismatch

  1. Basic candidate alias

    Base64 kavramsal taşıyıcıdır; alias encode edilmiş password değildir. HTTPS ayrı supplied koşuldur.

    Client
    Basic alias; HTTPS supplied
    Atlas API
    No request
    Trusted registry/policy
    Local password verifier alias
  2. Basic request ulaştı

    API scheme’i tanır; reversible encoding cryptographic proof değildir.

    Client
    Waiting
    Atlas API
    Received Basic candidate; verification pending
    Trusted registry/policy
    Local password verifier alias
  3. Local verifier mismatch

    Supplied verify predicate false’dur. Encoding parse olmuş olsa da authenticated subject yoktur.

    Client
    Waiting
    Atlas API
    Credential invalid; no subject
    Trusted registry/policy
    Verifier unchanged
  4. Authentication denial ulaştı

    Generic failure response gelir; private representation verilmez.

    Client
    Authentication failed; no private content
    Atlas API
    Response: authentication denied
    Trusted registry/policy
    Verifier unchanged

ROLLER · STATE · VERİ AKIŞI

Request taşıyıcısı ile server anlamı farklıdır

Atlas API’sine bir credential string ulaşması yalnız taşıma observation’ıdır. Server bunun hangi scheme’e ait olduğunu, geçerli olup olmadığını, hangi client/subject context’ini temsil ettiğini ve request’e hangi permission’ı verdiğini belirlemelidir.

Token genel olarak bir protocol içinde başka bir state veya hakkı temsil eden string olabilir. Her token JWT değildir, her token bearer değildir ve her API key bir user session değildir. Opaque token’ın anlamı server registry’den çözülebilir; self-contained token verifiable alanlar taşıyabilir. Format tek başına kullanım policy’sini açıklamaz.

HTTP Basic: Base64 encoding, encryption değil

RFC 7617 Basic scheme’de user-id ve password bir user-pass değerinde birleştirilir ve Base64 ile temsil edilir. Authorization header’ında scheme adı Basic’tir. Bu encoding geri dönüştürülebilir temsil sağlar; password’ü encrypt etmez, bir hash verifier da üretmez.

Basic için external secure transport, tipik olarak HTTPS/TLS gerekir. TLS credential’ı network boyunca korur; application endpoint’i yine credential’ı işler ve log redaction gerektirir. Bir Basic header görmek bağlantının TLS kullandığını veya doğru account’u doğruladığını tek başına kanıtlamaz.

Server challenge’ı WWW-Authenticate ile scheme ve realm bildirir. Realm bir protection-space etiketi, role ya da tenant authorization belgesi değildir. Client credential reuse davranışı bu protection-space bağlamıyla ilişkilidir; Authorization header’ı cookie scope mekanizmasıyla aynı şey değildir.

API key: kimin veya hangi projenin anahtarı?

API key’in anlamı ürün sözleşmesine bağlıdır. Bir key application/project attribution, quota veya paid plan ile ilişkili olabilir; başka tasarımda service principal credential’ı olabilir. “API key valid” sonucu Duru adlı end user’ın authenticate olduğu anlamına otomatik gelmez.

Güncel Google Cloud dokümanı bu farkı somutlaştırır: standard API key request’i billing/quota project’iyle ilişkilendirir ve principal authenticate etmez; service account’a bound authorization key ayrı türdür. Bu Google örneğinin bütün ürünlerde aynı sınıfları zorunlu kıldığını varsayma.

Atlas fixture’ında key-cover-app bir application binding’idir ve public cover fetch amacıyla sınırlıdır. Registry bir end-user subject vermez. Bu key ile Duru’nun private note’u istendiğinde user/resource policy şartı sağlanmaz; key’in tanınması onu permission’a yükseltmez. API key taşıyan header adı ürünün API sözleşmesidir; evrensel bir HTTP API-key scheme’i diye uydurulmaz.

Bearer: possession yeterli proof olabilir

RFC 6750 bearer credential’da token’a sahip taraf, kullanmak için ayrı bir cryptographic key possession proof’u vermek zorunda değildir. Bu yüzden token confidentiality kritik sınırdır. Bearer “token içeriği okunamıyor” demek değildir; opaque string de JWT gibi readable payload taşıyan token da bearer olarak kullanılabilir.

OAuth bearer access token genellikle Authorization: Bearer üzerinden resource server’a taşınır. Resource server token’ı ilgili kullanım kurallarıyla değerlendirir; possession tek başına her token’ın valid olduğu veya her resource’a izin verdiği anlamına gelmez.

Bu fixture’daki bearer-duru-read, authoritative registry’de subject-duru, Atlas API audience ve read:own-note scope ile ilişkilidir. Request yanlış audience, expired/revoked state veya eksik action permission taşıyorsa uygun trust/policy boundary’de reddedilir. JWT formatındaki local claim/signature ayrıntıları WEB-14.03’te açılır.

Transport, storage ve policy ayrı savunmalardır

TLS in-transit koruma sağlar; token’ın yanlış log’a yazılmasını veya yanlış client storage’a konmasını kendiliğinden önlemez. Password, API key ve bearer credential’ı URL’ye koymak history, log ve referrer gibi yerlere gereksiz yayılma riski doğurur. İlgili protocol’un protected header/body taşımasını tercih et.

Application secret’ını frontend bundle’a koyarak gizli tutamazsın. Browser’a verilmesi gereken credential için lifetime, storage visibility, XSS/CSRF sınırları ve server validation birlikte düşünülür. RFC 6750 bearer kullanımı ile cookie tabanlı session davranışını isimleri benzer diye birleştirme.

Key rotation/revocation, credential’ın future acceptance’ını değiştirir; client’taki bütün kopyaları sihirli biçimde silmez. Allowed client, audience, action ve tenant scope’u server’ın onayladığı boundary’de uygulanır. API key’i tek savunma olarak sensitive resource’a bağlamak yeterli genel yaklaşım değildir.

401, 403 ve challenge’ın amacı

HTTP authentication challenge ile application permission denial farklıdır. Basic ve Bearer scheme’leri challenge/response framework’ünde kendi anlamlarına sahiptir. OAuth bearer için invalid_token ve insufficient_scope farklı sebeplerdir; status ve WWW-Authenticate response’ı protocol’a göre düzenlenir.

Fixture’ın API-key-denial case’i kendi ürün policy’sini, Basic-mismatch case’i credential verification failure’ı gösterir. Bunlar gerçek HTTP capture değildir. End user response’ını güvenli ve anlaşılır tutarken secret içermeyen internal reason ile hangi boundary’nin karar verdiğini gözleyebilirsin.

2. Red · Güven ve etki

Hareket olmadan bütün senaryoları oku

Key, user değil

  1. Carrier tipi seçildi

    Bu branch application-defined X-Atlas-Key header’ını kullanır. Field adı fixture contract’ıdır; evrensel bir API-key authentication scheme’i değildir.

    Credential carrier
    application-defined API key header
    Binding registry
    Binding kurulmadı
    Action policy
    Resource verilmedi
  2. Credential validity ayrı okundu

    credentialValid=true key-cover-app kaydının tanındığını gösterir. Recognition tek başına bu request için end-user subject kurmaz.

    Credential carrier
    Credential valid=true
    Binding registry
    Binding kurulmadı
    Action policy
    Resource verilmedi
  3. Binding kind’i korunuyor

    bindingKind=application attribution ve subject=null kalır. Allowed purpose public cover fetch’tir; Duru identity’si bu application kaydından türetilmez.

    Credential carrier
    Credential valid=true
    Binding registry
    Application attribution; no user
    Action policy
    Resource verilmedi
  4. Private action koşulu değerlendirildi

    Action read Duru private note için gereken end-user binding yoktur. Bu ürünün key contract’ı private note yetkisi vermediğinden actionAllowed=false’tur.

    Credential carrier
    Credential valid=true
    Binding registry
    subject=null
    Action policy
    actionAllowed=false
  5. Representation teslimi durduruldu

    representationDelivered=false bu negatif sonucun veri sınırıdır. Tanınan key’in farklı bir üründe farklı principal’a bağlanabilmesi, burada eksik Duru binding’ini tamamlamaz.

    Credential carrier
    Validity: true
    Binding registry
    User subject yok
    Action policy
    Representation verilmedi
  6. Carrier’a fazla authority verilmedi

    Bu case valid application credential ile private-user denial’ı ayırır. Header ismine göre değil, registry binding ve action policy’ye göre hüküm verilir.

    Credential carrier
    Application credential tanındı
    Binding registry
    User binding yok
    Action policy
    Private resource verilmedi

Basic mismatch

  1. Carrier tipi seçildi

    Basic branch’inde BASIC_ALIAS_NOT_BASE64 etiketi kullanılır. Bu inert etiket gerçek Base64 credential veya kullanılabilir password taşımaz.

    Credential carrier
    Basic
    Binding registry
    Binding kurulmadı
    Action policy
    Resource verilmedi
  2. Credential validity ayrı okundu

    credentialValid=false olarak verilmiştir. Basic’i parse etmek veya Base64 biçimini bilmek password verify başarısı üretmez; encoding encryption değildir.

    Credential carrier
    Credential valid=false
    Binding registry
    Binding kurulmadı
    Action policy
    Resource verilmedi
  3. Binding kind’i korunuyor

    bindingKind=user-id/password candidate’tir, fakat doğrulama başarısız olduğundan subject=null kalır. Candidate bir trusted user context’i değildir.

    Credential carrier
    Credential valid=false
    Binding registry
    Unverified candidate; no user
    Action policy
    Resource verilmedi
  4. Private action koşulu değerlendirildi

    Credential kabulü sağlanmadığından bu branch actionAllowed=false kalır. Authorization adlı header’ın bulunması resource authorization yapılmış demek değildir.

    Credential carrier
    Credential valid=false
    Binding registry
    subject=null
    Action policy
    actionAllowed=false
  5. Representation teslimi durduruldu

    representationDelivered=false korunur. HTTPS taşıma koruması bir password mismatch’i başarıya çevirmez; transport ve credential sonucu ayrı kontrollerdir.

    Credential carrier
    Validity: false
    Binding registry
    User subject yok
    Action policy
    Representation verilmedi
  6. Carrier’a fazla authority verilmedi

    Bu case Basic candidate ile trusted subject’i ayırır. Encoding biçimi gizlilik, credential validity veya permission kanıtı olarak genişletilmez.

    Credential carrier
    Credential doğrulanmadı
    Binding registry
    User binding yok
    Action policy
    Private resource verilmedi

VARSAYIM · SINIR · KONTROL

Header varlığı identity kanıtı değildir

Defensive review’da scheme, presented alias, registry binding, validity ve action decision’ı ayrı gör. Authorization adlı header’ın varlığı resource authorization’ının yapıldığını göstermez; isim protocol convention’dır.

Key-cover-app tanınıyor ama subject null ise Duru’nun private note’u için gereken subject binding yoktur. Bearer token’ın subject’i çözülse bile action/resource policy tekrar gerekir. Basic encoding’i doğru parse etmek de password verify başarısını üretmez.

Carrier’ın adı ile credential’ın verdiği authority arasında otomatik eşitlik kurma. Bu fixture’daki application key, cover servisini tanır; private note için bir end-user subject üretmez. İnceleme notunda “key registry tarafından tanındı” ve “Duru için object/action izni çözüldü” iki ayrı satırdır. Başka bir üründe key farklı bir principal’a bağlanabilir; bu yüzden sonucu header adına göre değil, ürünün doğrulanmış binding contract’ına ve o request’in policy kararına göre açıklarsın.

Credential yayılımını azalt

Log, error message, analytics ve cache key içinde raw credential gereksizdir. Diagnostic gözlemde scheme ve opaque correlation alias yeterli olabilir. URL’ye taşınan credential’ı “Base64 olduğu için güvenli” veya “JWT olduğu için public” sayma.

Defterde raw credential yerine correlation alias, binding kind ve action sonucu bulunur. Böylece encoding’in biçimi ile credential validity ve resource authority ayrı gözlenir.

3. Blue · Güvenli geliştirme ve savunma

Hareket olmadan bütün senaryoları oku

Binding incelemesi

  1. Credential observation seçildi

    İnceleme normal Bearer satırında scheme, bindingKind, subject ve actionAllowed alanlarını birlikte kullanır. Raw credential yerine alias ile ilişki kurulur.

    Carrier observation
    Bearer normal row
    Contract incelemesi
    Contract incelenmedi
    Kanıt hükmü
    Geniş hüküm yok
  2. Contract sonucu okundu

    bindingKind=verified user grant ve subject=subject-duru verilmiştir. Audience Atlas API ve scope read:own-note bu ürünün grant kapsamını açıklar.

    Carrier observation
    Bearer normal row
    Contract incelemesi
    User grant; Atlas API
    Kanıt hükmü
    Geniş hüküm yok
  3. Action veya validity karşılaştırıldı

    action=read own note, actionAllowed=true ve representationDelivered=true birlikte kayıtlıdır. Bu satır administration action’ı için grant içermez.

    Carrier observation
    Bearer normal row
    Contract incelemesi
    Own note allowed; delivered
    Kanıt hükmü
    Geniş hüküm yok
  4. Başka principal türüyle karşılaştırıldı

    API-key satırı valid olsa da bindingKind=application attribution ve subject=null taşır. Bearer’ın user grant’i bu ayrı application credential’a aktarılmaz.

    Carrier observation
    Bearer normal row
    Contract incelemesi
    Binding türleri farklı
    Kanıt hükmü
    Geniş hüküm yok
  5. Eksik runtime kanıtı ayrıldı

    Satır declared grant ve delivery kararını gösterir. Actual token validation, güncel revocation veya browser receipt bu artifact’te ayrıca ölçülmüş değildir.

    Carrier observation
    Bearer normal row
    Contract incelemesi
    Declared decision biliniyor
    Kanıt hükmü
    Runtime validation bilinmiyor
  6. Observation secret taşımadan kapandı

    Scheme ve bindingKind, subjectResolved ve actionDecision ile birlikte yorumlanır. Credential raw string’i olmadan grant kapsamı açıklanabilir; sonuç farklı resource veya ürünlere genişletilmez.

    Carrier observation
    Bearer normal row
    Contract incelemesi
    Scope: own note
    Kanıt hükmü
    Yalnız seçilen grant

Transport kanıtı

  1. Credential observation seçildi

    İnceleme Basic mismatch satırında encoding, transport ve credentialValid alanlarını ayırır. Observation gerçek TLS capture veya certificate sonucu içermez.

    Carrier observation
    Basic mismatch row
    Contract incelemesi
    Contract incelenmedi
    Kanıt hükmü
    Geniş hüküm yok
  2. Contract sonucu okundu

    Base64 is representation, not encryption alanı encoding sınırını gösterir. HTTPS supplied separately ifadesi, transport koşulunun credential match’ten bağımsız olduğunu belirtir.

    Carrier observation
    Basic mismatch row
    Contract incelemesi
    Encoding ≠ encryption
    Kanıt hükmü
    Geniş hüküm yok
  3. Action veya validity karşılaştırıldı

    credentialValid=false, subject=null ve actionAllowed=false kayıtlıdır. Transport koşulunun varlığı bu negatif decision’ı değiştirmez.

    Carrier observation
    Basic mismatch row
    Contract incelemesi
    Invalid; no subject; denied
    Kanıt hükmü
    Geniş hüküm yok
  4. Başka principal türüyle karşılaştırıldı

    API-key satırında validity true olabilirken user subject yine null’dur. Basic’in formatı ile key recognition aynı kontrol değildir; ikisi kendi binding contract’ıyla değerlendirilir.

    Carrier observation
    Basic mismatch row
    Contract incelemesi
    Binding türleri farklı
    Kanıt hükmü
    Geniş hüküm yok
  5. Eksik runtime kanıtı ayrıldı

    HTTPS koşulu verilmiştir, fakat peer identity, certificate validation ve proxy sonrası transport gözlemi yoktur. Bu eksiklik, cleartext gözlendi hükmü de değildir.

    Carrier observation
    Basic mismatch row
    Contract incelemesi
    Declared decision biliniyor
    Kanıt hükmü
    UNKNOWN: observed TLS path
  6. Observation secret taşımadan kapandı

    Basic mismatch ile transport evidence gap iki ayrı bulgudur. Encoding çıktısı veya raw password eklemek bu boşluğu tamamlamaz; gerekirse transport gözlemi kendi kaynağından alınır.

    Carrier observation
    Basic mismatch row
    Contract incelemesi
    Credential mismatch biliniyor
    Kanıt hükmü
    Transport ayrıca kanıt ister

UYGULAMA · GÜVENLİK KONTROLÜ · DOĞRULAMA

Credential türünü ve subject sözleşmesini açık yaz

Endpoint için kabul edilen scheme ve credential formatını belirle. Registry/token validation sonucu end-user subject, service principal veya project attribution mı veriyor? Bu farkı policy’nin input type’ında koru.

Application credential’ını otomatik user session’a dönüştürme. Key’i product contract’a göre restrict/revoke et; user action için ayrıca gerekli authenticated subject/resource relationship’i çöz.

Güçlü transport ve redaction kullan

Basic ve bearer gibi sensitive credential transport’unda HTTPS/TLS uygula; endpoint certificate validation’ı client sorumluluğunun parçasıdır. Reverse proxy sonrası trusted transport boundary’yi de tasarımda belirt.

URL credential’larını önle; header/body handling ve log redaction policy’sini kur. Frontend’a server secret verme. Credential expiry/revocation ile client cleanup’ın farklı adımlar olduğunu UI model’inde koru.

Acceptance’ı action boundary’sinde kapat

Token/key recognition sonrası validity, issuer/audience veya registry binding ve action permission’ı uygula. Basic için password verifier ve account policy gerekir. Geçerli token’ın yanlış resource’a kabul edilmesi format parsing başarısıyla savunulamaz.

Audit’te credentialType, bindingKind, subjectResolved ve actionDecision alanları kullan. Secret veya encoding çıktısı olmadan da key-app/no-user ile bearer-user/allowed ayrımı açık kalır.

ŞİMDİ VAKAYA UYGULA

Tanınan credential hangi principal’a bağlanır?

Bearer user grant, application key ve Basic candidate farklı binding türleridir. Credential recognition, transport ve private action permission ayrı değerlendirilir.

Vakadaki doğrulanmış actor, tenant ilişkisi ve requested action için gereken kararları ayır. Authentication veya proof başarısını object permission yerine kullanma.

Bağlı vaka dosyasını aç ↗

ÖRNEĞİ BİRLİKTE OKUYALIM

Credential carrier ve binding defteri

Bir alan seç; hangi sonucu desteklediğini ve nerede yetersiz kaldığını incele.

Ham kaydı ve alan açıklamalarını oku
{
  "aliasesOnly": true,
  "cases": [
    {
      "case": "normal",
      "scheme": "Bearer",
      "wireShape": "Authorization: Bearer BEARER_ALIAS_ONLY",
      "credentialAlias": "bearer-duru-read",
      "bindingKind": "verified user grant",
      "subject": "subject-duru",
      "audience": "Atlas API",
      "scope": "read:own-note",
      "credentialValid": true,
      "action": "read own note",
      "actionAllowed": true,
      "representationDelivered": true
    },
    {
      "case": "api-key-private-denied",
      "scheme": "application-defined API key header",
      "wireShape": "X-Atlas-Key: KEY_ALIAS_ONLY (fixture contract, not a standard scheme)",
      "credentialAlias": "key-cover-app",
      "bindingKind": "application attribution",
      "subject": null,
      "allowedPurpose": "public cover fetch",
      "credentialValid": true,
      "action": "read Duru private note",
      "actionAllowed": false,
      "representationDelivered": false
    },
    {
      "case": "basic-mismatch",
      "scheme": "Basic",
      "wireShape": "Authorization: Basic BASIC_ALIAS_NOT_BASE64",
      "credentialAlias": "basic-candidate-alias",
      "bindingKind": "user-id/password candidate",
      "encoding": "Base64 is representation, not encryption",
      "transport": "HTTPS supplied separately",
      "credentialValid": false,
      "subject": null,
      "actionAllowed": false,
      "representationDelivered": false
    }
  ],
  "selector": {
    "xml": "<carriers><decision scheme=\"bearer\" valid=\"true\" userSubject=\"true\" allowed=\"true\" delivered=\"true\"/><decision scheme=\"api-key\" valid=\"true\" userSubject=\"false\" allowed=\"false\" delivered=\"false\"/><decision scheme=\"basic\" valid=\"false\" userSubject=\"false\" allowed=\"false\" delivered=\"false\"/></carriers>",
    "xpath": "count(/carriers/decision[@delivered=\"true\" and (@valid!=\"true\" or @userSubject!=\"true\" or @allowed!=\"true\")])",
    "expected": 0,
    "positiveFixtureXml": "<carriers><decision valid=\"true\" userSubject=\"false\" allowed=\"false\" delivered=\"true\"/></carriers>",
    "positiveExpected": 1
  }
}
wireShape
Yalnız taşıyıcı biçimini anlatan invalid alias string; çalıştırılacak HTTP request değildir.
bindingKind / subject
Application attribution ile end-user context ayrımı; key tanınması user doğrulaması değildir.
credentialValid / actionAllowed
Recognition/validity ve resource permission ayrı predicate’lerdir.
representationDelivered
Bu fixture private-note policy’sinin nihai sonucu.

Authorization string’leri gerçek credential değildir; Basic alias bilerek Base64 değildir. Registry local logical data’dır. TLS, Base64, credential verify, OAuth ve gerçek API endpoint’i çalıştırılmadı. Atlas key header yalnız fixture contract’tır.

İki yanlış kanı

Basic Base64 ile encrypt eder; bearer token JWT olmak zorundadır.

Base64 reversible encoding’dir, TLS ayrı korumadır. Bearer possession semantics’tir; token opaque veya self-contained olabilir.

Valid API key Duru’nun authenticate olduğunu ve private note’a yetkili olduğunu kanıtlar.

Key binding product contract’a bağlıdır; application/project veya service principal olabilir. End-user subject ve resource permission ayrıca çözülür.

SIRA SENDE

Bu hikâyeyi sen çöz.

Sonucu tahmin et, kanıtın sınırını bul ve nedenini kendi cümlenle anlat.

Public cover için application key geçerli. Action, Duru’nun private note’unu okumak. Delivery olur mu?

  1. Hayır. Application attribution kullanıcı izni değildir.
  2. Evet. Geçerli API key bütün kullanıcı resource’larını açar.
Gerekçeli cevabı oku

Hayır. Application attribution kullanıcı izni değildir. — subject=null ve actionAllowed=false. Geçerli key bu private note için kullanıcı izni kurmaz.

Basic encoding ve HTTPS neden ayrı alanlardır?

Dersten seçilen artifact alanları; öğretim örneği

cases[2].encoding
Base64 is representation, not encryption
cases[2].transport
HTTPS supplied separately
cases[2].credentialValid
false
  1. Basic Base64, credential’ı secret key olmadan encrypt eder.
  2. Base64 encryption değildir; HTTPS taşıma koruması ayrıca gerekir.
Gerekçeli cevabı oku

Base64 encryption değildir; HTTPS taşıma koruması ayrıca gerekir. — Basic user-id/password adayını taşır. Encoding ne credential’ın geçerliliğini ne channel güvenliğini doğrular.

Bearer taşıma şekli token’ın JWT olmasını veya private action’a izin vermesini garanti eder mi?

Gerekçeli cevabı oku

Bearer, token’ı elinde bulundurarak kullanmaya dayanan taşıma semantics’ini tanımlar. Token opaque veya structured olabilir. Bu örnekte grant Atlas API audience ve read:own-note scope’una bağlıdır. Format’ı decode etmek veya geçerli taşıyıcı kullanmak güncel object/action izni sağlamaz. API key header adı da application’ın kendi sözleşmesidir.

□ Bearer scheme ile JWT formatını ayırdım.

□ Audience/scope kontrollerini action policy’sinden ayırdım.

Uygulama konsolunu aç · request / response / browser
Request, URL, cookie ve DOM örneklerini ayrıca aç

Kaynaklar ve kapsam