Valitse rooli ennen työkalua
OAuth-käyttöoikeustunniste voi olla läpinäkymätön tai käyttää JWT:tä. JWT:n purkaminen ei todenna aitoutta; allekirjoitettu JWT ei automaattisesti salaa sisältöään. Yhdyskäytävä ei korvaa palvelun liiketoimintavaltuutusta.
| Osa | Rooli | Näkyvä raja |
|---|---|---|
| OAuth 2.0 | Delegoitu valtuutus. | Ei yksin käyttäjän kirjautumisprotokolla. |
| OpenID Connect | Todennus OAuth 2.0:n päälle. | Vaatii profiilin ja tunnisteen tarkistuksen. |
| JWT | Väitteiden esitysmuoto. | Purkaminen, allekirjoitus ja salaus ovat eri asioita. |
| API-yhdyskäytävä | Yhteiset sisääntulokontrollit. | Ei korvaa objektikohtaisia oikeuksia. |
Tarkista protokolla ja jokainen pääsy
- Valitse asiakkaalle sopiva kulku. Noudata käyttäjäpoluissa nykyisiä valtuutuskoodi- ja PKCE-suosituksia, ylläpidettyä kirjastoa ja tarkasti valvottuja uudelleenohjauksia.
- Tarkista hyväksyttävän JWT:n allekirjoitus, sallitut algoritmit, myöntäjä, vastaanottaja ja profiilin aikarajat. Hylkää toiseen käyttöön tarkoitettu tunniste.
- Tarkista jokainen objekti, toiminto ja organisaatio. Testaa tilien välisiä oikeuksia kuvitteellisilla tiedoilla; yleinen rooli tai laajuus ei aina riitä.
Suunnittele vanheneminen, peruminen ja häiriöt
Dokumentoi uusiminen, avainten kierto, salaisuuksien menetys ja perumisstrategia. Paikallinen tarkistus ei automaattisesti saa tietoa etäperumisesta. Minimoi tunnistetiedot ja lokit; JWT tai kiintiöt eivät yksin takaa turvallisuutta tai vaatimustenmukaisuutta.
Alkuperäiset lähteet
- IETF RFC 9700 — OAuth 2.0 Security Best Current Practice [EN]
- IETF RFC 8725 — JWT Best Current Practices [EN]
- OpenID Foundation — OpenID Connect Core 1.0 [EN]
- OWASP — Authorization Cheat Sheet [EN]
Yhdyskäytävä ei korvaa objektin valtuutusta.
API:n tulisi varmistaa sekä, että tunnus on tarkoitettu sille että että kutsuja voi suorittaa toiminnon objektille. Kelvollinen JWT-allekirjoitus tai onnistunut OAuth-kirjautuminen ei vahvista näitä käyttöoikeuksia. Testaa vierekkäisiä identiteettejä ja etuoikeutettuja toimintoja.
- Hylkää kelvollinen token, joka on tarkoitettu toiselle yleisölle.
- Testaa tilien välinen käyttöoikeus, yksityiset kentät ja hallinnolliset toiminnot.
- Harjoittele vanhenemista ja roolin vaihtoa kirjoittamatta tokeneita lokeihin.
Ensisijainen lähde: IETF — RFC 9700, OAuth 2.0 Security Best Current Practice. Aiheeseen liittyvä menetelmä: lue käytännön opas.
Passkeyt: verkkotunnuksen ja RP ID:n vaihto
Erota tili, verkkoalkuperä ja RP ID, jotta tunnistetietoja ei siirretä hiljaisesti uuteen rajaukseen.
- Kirjaa vanhat ja uudet alkuperät, RP ID:t ja niihin liittyvät tilit. Sama tilinimi ei tee passkeysta kelvollista toiselle RP ID:lle. Tarkista WebAuthnin sallimat yhdistelmät ja siirtymän aikana toimivat pääsypolut.
- Tarkista valtuutetussa testiympäristössä haaste, alkuperä, RP ID ja tilisidonta sopivalla kirjastolla. Testaa odottamaton alkuperä ja toistettu haaste. RP ID:n vaihto vaatii uuden tunnistetun rekisteröinnin; rivin kopiointi ei siirrä avainta.
- Testaa käyttäjä, jolla on vain vanha tunniste, palautuminen ja avoimet istunnot. Määritä polkujen avaus ja poisto testatulla paluulla. Rekisteröinti uudessa tunnuksessa ei osoita kaikkien vanhojen istuntojen peruuttamista.
Toistettava hyväksyntätapaus
Kuvitteellinen esimerkki: tiedot eivät kuvaa asiakasta tai havaittua tulosta.
Näytä tapauksen tiedot
{
"old_origin": "https://login.old.example",
"old_rp_id": "old.example",
"new_origin": "https://login.new.example",
"new_rp_id": "new.example",
"same_service_account": true,
"expected": "authenticated_new_registration"
}Odotettu päätös
Kuvitteellinen esimerkki: tili säilyy, mutta old.example vaihtuu new.exampleksi eri RP ID:llä. Vanhaa tunnistetta ei voi hiljaisesti siirtää; uusi rekisteröinti seuraa suunniteltua tunnistettua polkua.
Voiko tietokantamuutos vaihtaa passkeyn RP ID:n?
Ei. RP ID kuuluu tunnisteen varmennettuun rajaukseen. Valmistele kelvollinen uusi rekisteröinti ja tunnistettu tilikytkentä.
Ensisijainen lähde: W3C — Web Authentication Level 2. Aiheeseen liittyvä menetelmä: lue käytännön opas.
TLS-uusiminen: varmista todella tarjottu varmenne
Seuraa uusimista päätepisteisiin ja asiakkaille ennen muutoksen valmistumisen ilmoittamista.
- Luettele nimet, CDN:t, kuormantasaajat, välityspalvelimet ja sisäiset varmennetta tarjoavat yhteydet. Kirjaa tarjottu varmenne, ketju, päättyminen ja omistaja. Myöntäminen ei todista asennusta joka solmuun. Suojaa yksityiset avaimet äläkä kirjaa niitä luetteloon.
- Testaa automaatio tarjoajan testiympäristössä, jos sellainen on. Tarkista haasteet, SAN-nimet, suojattu tallennus ja komponenttien uudelleenlataus. Vältä myöntämistä joka käynnistyksessä, jos avainpolitiikan mukainen käyttökelpoinen varmenne on olemassa.
- Tarkista nimet, päivät ja luottamusketju tuetuilla asiakkailla olennaisilla reiteillä. Pidä TLS-tarkistus käytössä. Valvo tarjotun varmenteen päättymistä, ei vain ajastimen tilaa. Paluu vaatii voimassa olevan varmenteen ja vaarantumattoman avaimen; muuten korjaa tai eristä päätepiste.
Toistettava hyväksyntätapaus
Kuvitteellinen esimerkki: tiedot eivät kuvaa asiakasta tai havaittua tulosta.
Näytä tapauksen tiedot
{
"issuance_succeeded": true,
"proxy_count": 2,
"proxies_serving_expected_certificate": 1,
"other_proxy_certificate_expired": true,
"tls_verification_enabled": true,
"expected": "change_incomplete_fix_and_verify_client_paths"
}Odotettu päätös
Kuvitteellinen esimerkki: uusiminen onnistuu, mutta toinen kahdesta välityspalvelimesta tarjoaa vanhentunutta varmennetta. Muutos on kesken; korjaa piste ja tarkista asiakasreitit poistamatta TLS-tarkistusta.
Ensisijainen lähde: Let’s Encrypt — Integration Guide. Aiheeseen liittyvä menetelmä: lue käytännön opas.
Tutki CISAn KEV-luetteloa
Tämän kieliversion tarkemmat lähdekuvaukset ovat englanniksi.
One identifier can span several technical layers
An entry may concern a library, server or component embedded in an appliance. Search the exact name, known dependencies and the distributed product’s advisory. Catalogue aliases are not a complete list of affected versions.
- Connect the CVE, component supplier and final-product supplier.
- Check version, configuration and execution path in the authorised environment.
- Do not infer remediation from an empty search result.
Tutki luetteloa ja menetelmää →
CISA KEV · 2026.11.06 · Documentary review : 2026-11-07
Laajennukset: oikeudet ja käyttö
Tämän kieliversion tarkemmat lähdekuvaukset ovat englanniksi.
Robust authentication does not describe extension access
Phishing resistance does not remove the need to examine what runs in the browser after a session opens. A manifest provides clues about cookies, scripting, debugging and identity without establishing collection.
- Test approved extensions in a profile dedicated to sensitive operations.
- For identity, inspect OAuth scopes and recipients; this permission does not enumerate identity-provider rights.
- Distinguish session revocation, token revocation, extension disablement and native-component removal.
Read the permission directory and manifest examples →
Google Chrome · Stay secure · Documentation consulted 2026-10-23; browser behaviour remains version-dependent