Liittoutunut identiteetti: SAML, OAuth ja OpenID Connect
Oppikaa, miten SSO, SAML-väitteet, OAuth 2.0 -kulut ja OpenID Connect -tokenit mahdollistavat käyttäjien turvallisen kertatunnistautumisen useissa sovelluksissa.
Liittoutunut identiteetti: SAML, OAuth ja OpenID Connect on ilmainen Cloud & IT Cert Prep-oppitunti CoddyKitissä. Tämä on oppitunti 4/4. Voit lukea koko oppitunnin alta ilmaiseksi ja harjoitella sen jälkeen käytännössä selaimessa sisäänrakennetulla koodieditorilla ja ympäri vuorokauden käytettävissä olevan tekoälytuutorin avulla. Oppitunti kuuluu Cloud & IT Cert Prep-oppimispolkuun, ja edistymisesi synkronoituu verkon ja CoddyKit-sovelluksen välillä. Cloud & IT Cert Prep-kurssilla on yhteensä 4 oppituntia.
Identiteetin ongelma toimialueiden välillä
Nykyaikaisissa yrityksissä työntekijöiden on käytettävä kymmeniä sovelluksia — pilvisovelluksia, SaaS-työkaluja, kumppaniportaaleja ja sisäisiä järjestelmiä — joita eri organisaatiot saattavat ylläpitää. Erillisten tilien luominen ja hallinta jokaista palvelua varten on tietoturvan kannalta heikkoa (tunnistetietojen määrän kasvu) ja tehotonta. Federoitu identiteetti ratkaisee tämän sallimalla identiteetintarjoajan (IdP) — luotetun ja auktoritatiivisen identiteetin lähteen — todentaa käyttäjät ja jakaa todennetun identiteetin palveluntarjoajille (SP) organisaatioiden rajojen yli. Käyttäjät todentavat itsensä kerran ja saavat pääsyn useisiin järjestelmiin syöttämättä tunnistetietoja uudelleen.
Kertakirjautumisen (SSO) perusteet
Kertakirjautuminen (SSO) mahdollistaa käyttäjien todentamisen kerran ja useiden sovellusten käytön istunnon aikana ilman uutta todennusta. Käyttäjä kirjautuu identiteetintarjoajaan (yrityksen Active Directory, Okta tai Azure AD), saa istuntotunnuksen tai väitteen ja esittää tämän tunnuksen jokaiselle palveluntarjoajalle, jossa hän vierailee. SSO parantaa tietoturvaa vähentämällä käyttäjien hallinnoitavien salasanojen määrää (mikä vähentää salasanojen uudelleenkäyttöä), mahdollistamalla keskitettyjen todennuskäytäntöjen valvonnan ja sallimalla käyttöoikeuksien välittömän perumisen kaikista integroiduista sovelluksista, kun tili poistetaan käytöstä IdP-tasolla.
SAML 2.0: XML-pohjainen federaatio
SAML (Security Assertion Markup Language) 2.0 on XML-pohjainen avoin standardi todennus- ja valtuutustietojen vaihtamiseen identiteetintarjoajien ja palveluntarjoajien välillä. SAML-kulku: (1) käyttäjä siirtyy palveluntarjoajaan (esimerkiksi Salesforceen), (2) SP uudelleenohjaa käyttäjän identiteetintarjoajaan (esimerkiksi Oktaan), (3) käyttäjä todentaa itsensä IdP:ssä, (4) IdP myöntää allekirjoitetun XML-muotoisen SAML-väitteen, joka sisältää käyttäjän identiteetin ja attribuutit, (5) väite palautetaan SP:lle, (6) SP tarkistaa väitteen allekirjoituksen IdP:n julkisella avaimella ja myöntää käyttöoikeuden. SAML:ää käytetään laajasti yritysten verkkosovellusten SSO-ratkaisuissa.
<!-- Simplified SAML Assertion structure -->
<saml:Assertion xmlns:saml='urn:oasis:names:tc:SAML:2.0:assertion'
IssueInstant='2026-06-21T10:00:00Z'
ID='_abc123'>
<saml:Issuer>https://idp.company.com</saml:Issuer>
<saml:Subject>
<saml:NameID>alice@company.com</saml:NameID>
</saml:Subject>
<saml:Conditions NotBefore='2026-06-21T10:00:00Z'
NotOnOrAfter='2026-06-21T10:05:00Z'/>
<saml:AttributeStatement>
<saml:Attribute Name='groups'>
<saml:AttributeValue>Sales</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
<!-- Signature verifies IdP signed this assertion -->
</saml:Assertion>SAML-roolit: IdP, SP ja päämies
SAML-federaatioon osallistuu kolme osapuolta. Päämies on käyttöoikeutta pyytävä käyttäjä (tai järjestelmä), joka käynnistää todennusprosessin. Identiteetintarjoaja (IdP) on auktoritatiivinen identiteetin lähde, joka todentaa päämiehen ja myöntää väitteitä — esimerkkejä ovat Microsoft Azure AD, Okta, Ping Identity ja ADFS. Palveluntarjoaja (SP) käyttää väitettä ja myöntää sen perusteella käyttöoikeuden — esimerkkejä ovat Salesforce, Google Workspace, AWS ja mikä tahansa SAML-yhteensopiva sovellus. SP ja IdP muodostavat luottamussuhteen etukäteen vaihtamalla metatietoja, jotka sisältävät toistensa päätepisteiden URL-osoitteet ja allekirjoitusvarmenteet.
OAuth 2.0: valtuutuskehys
OAuth 2.0 on valtuutuskehys (ei todennusprotokolla), jonka avulla kolmannen osapuolen sovellus voi käyttää resursseja käyttäjän puolesta paljastamatta käyttäjän tunnistetietoja. Tyypillinen käyttötapaus on: ”Salli tämän kuvankäsittelysovelluksen käyttää Google Photos -kuviasi.” OAuth 2.0 määrittää neljä roolia: resurssin omistaja (käyttäjä), asiakas (kolmannen osapuolen sovellus), valtuutuspalvelin (myöntää tunnuksia) ja resurssipalvelin (isännöi suojattua resurssia). Käyttäjä valtuuttaa asiakkaan, joka saa käyttöoikeustunnuksen esitettäväksi resurssipalvelimelle — käyttäjän varsinaista salasanaa ei tarvita missään vaiheessa.
OAuth 2.0:n valtuutuskoodivirta
Valtuutuskoodivirta on verkkosovellusten turvallisin OAuth 2.0 -virta. Kulku on seuraava: (1) asiakas uudelleenohjaa käyttäjän valtuutuspalvelimelle pyydettyjen käyttöalueiden kanssa; (2) käyttäjä todentaa itsensä ja antaa suostumuksensa valtuutuspalvelimella; (3) valtuutuspalvelin uudelleenohjaa käyttäjän takaisin lyhytkestoisen valtuutuskoodin kanssa; (4) asiakas vaihtaa koodin käyttöoikeustunnukseen (ja valinnaisesti päivitystunnukseen) palvelinten välisellä pyynnöllä käyttäjätunnistetietoja käyttäen; (5) asiakas käyttää käyttöoikeustunnusta kutsuessaan resurssipalvelinta. Koodin vaihto tapahtuu palvelinpuolella, mikä estää käyttöoikeustunnuksen paljastumisen selaushistoriassa tai lokeissa.
# OAuth 2.0 Authorization Code Flow (step 3-4)
# Step 3: User is redirected back to client with auth code
# GET https://app.example.com/callback?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz
# Step 4: Client exchanges code for access token (server-to-server)
curl -X POST https://auth.example.com/oauth2/token \
-d 'grant_type=authorization_code' \
-d 'code=SplxlOBeZQQYbYS6WxSbIA' \
-d 'redirect_uri=https://app.example.com/callback' \
-d 'client_id=client_abc' \
-d 'client_secret=secret_xyz'
# Response: {'access_token': 'MTQ0Nj...', 'token_type': 'Bearer', 'expires_in': 3600}OpenID Connect: todennuksen lisääminen OAuthiin
OpenID Connect (OIDC) on OAuth 2.0:n päälle rakennettu todennuskerros. OAuth tarjoaa vain valtuutuksen (käyttöoikeustunnukset osoittavat, mitä asiakas voi tehdä), kun taas OIDC lisää todennuksen (ID-tunnus osoittaa, kuka käyttäjä on). OIDC lisää OAuth-virtaan openid-käyttöalueen ja palauttaa allekirjoitetun JWT (JSON Web Token) -ID-tunnuksen käyttöoikeustunnuksen rinnalla. ID-tunnus sisältää käyttäjän tunnistavat väittämät (nimi, sähköpostiosoite ja sub [aiheen tunniste]). OIDC on nykyään kuluttajille suunnatun SSO:n hallitseva protokolla — ”Kirjaudu Googlella/Applella/Microsoftilla” -painikkeet käyttävät kaikki OIDC:tä.
# OIDC ID Token is a JWT with three base64url-encoded parts:
# header.payload.signature
# Decoded payload example:
# {
# 'iss': 'https://accounts.google.com',
# 'sub': '110169484474386276334',
# 'aud': 'client_id_abc123',
# 'exp': 1750000000,
# 'iat': 1749996400,
# 'email': 'alice@gmail.com',
# 'name': 'Alice Smith',
# 'email_verified': true
# }
# The signature is verified with the IdP's public key (from JWKS endpoint)JWT: tunnukset nykyaikaisessa todennuksessa
JSON Web Tokenit (JWT) ovat tiivis ja URL-osoitteissa turvallisesti käytettävä muoto, jolla osapuolten välisiä väittämiä esitetään. JWT koostuu kolmesta pisteillä erotetusta base64url-koodatusta osasta: otsake (algoritmi ja tunnuksen tyyppi), hyötykuorma (väittämät: iss, sub, aud, exp, iat ja mukautetut väittämät) sekä allekirjoitus (tunnuksen eheyden varmistava kryptografinen allekirjoitus). JWT:t ovat itsenäisesti sisältäviä — resurssipalvelin voi tarkistaa ne kutsumatta valtuutuspalvelinta, mikä parantaa suorituskykyä ja mahdollistaa tilattomat arkkitehtuurit. Keskeinen tietoturvavaatimus on aina tarkistaa JWT:n allekirjoitus sekä exp- (vanheneminen) ja aud- (kohdeyleisö) -väittämät.
# Decode a JWT (header and payload are just base64 encoded)
import base64, json
jwt = 'eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFsaWNlIiwiZXhwIjoxNzUwMDAwMDAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c'
parts = jwt.split('.')
print('Header:', json.loads(base64.b64decode(parts[0] + '==')))
print('Payload:', json.loads(base64.b64decode(parts[1] + '==')))
# Signature (parts[2]) must be verified with IdP public key!SAML vs. OAuth vs. OIDC: milloin mitäkin käytetään
On tärkeää ymmärtää, milloin kutakin standardia käytetään, sillä aihe kuuluu Security+ -kokeen keskeisiin sisältöihin. SAML 2.0: yritysten verkkosovellusten SSO, selainpohjaiset kulut ja XML-väitteet. Vanha mutta yrityksissä laajasti käytössä oleva standardi. OAuth 2.0: API-rajapintojen valtuutus eli kolmansien osapuolten sovelluksille myönnettävä rajattu pääsy resursseihin. Ei todenna käyttäjiä suoraan. OIDC: kuluttajien ja nykyaikaisten yritysten todennus (SSO), joka on rakennettu OAuth 2.0:n päälle. Palauttaa käyttäjän identifioivia JWT-ID-tunnuksia. Käytännössä yritysympäristöissä käytetään usein SAML:ää sovellusten SSO:hon ja OIDC:tä API- ja mobiilitodennukseen. Nykyaikaiset cloud-native-ympäristöt suosivat OIDC:tä SAML:n sijaan sen JSON/JWT-muodon ja paremman mobiilituen vuoksi.
Federaation hyökkäysvektorit
Federoidut identiteettijärjestelmät tuovat mukanaan tiettyjä hyökkäysvektoreita. Väitteen uudelleentoistohyökkäys: hyökkääjä sieppaa SAML-väitteen ja toistaa sen saadakseen käyttöoikeuden. Hyökkäystä torjutaan väitteiden lyhyellä voimassaoloajalla ja kertakäyttöisillä väitetunnuksilla. XML-allekirjoituksen kääriminen (XSW): SAML:ssä hyökkääjät voivat joskus muokata allekirjoitettua XML:ää siten, että väittämät muuttuvat mutta alkuperäisen sisällön allekirjoitus säilyy kelvollisena. JWT-algoritmien sekoittaminen: jos palvelin hyväksyy sekä RS256- (epäsymmetrinen) että HS256-algoritmit (symmetrinen), hyökkääjä voi väärentää JWT-tunnuksia käyttämällä palvelimen julkista avainta HS256:n HMAC-salaisuutena. Varmistakaa aina, että algoritmin otsake vastaa odotettua algoritmia. Avoimet uudelleenohjaimet: OAuth-uudelleenohjaus-URI-osoitteiden on vastattava täsmälleen toisiaan, jotta tunnusten varastaminen uudelleenohjauksella hyökkääjän hallitsemille sivustoille estetään.
Hakemistofederaatio ja SCIM
Yritysten identiteettifederaatio edellyttää usein käyttäjien identiteettitietojen synkronointia järjestelmien välillä. SCIM (System for Cross-domain Identity Management) on REST API -standardi käyttäjien käyttöoikeuksien automaattiseen luomiseen ja poistamiseen identiteetintarjoajan ja siihen yhdistettyjen palveluntarjoajien välillä. Kun uusi työntekijä lisätään Azure AD:hen (IdP), SCIM luo hänen tilinsä automaattisesti Salesforceen, Slackiin, GitHubiin ja muihin SCIM-yhteensopiviin sovelluksiin. Kun työntekijän työsuhde päättyy, SCIM poistaa kaikki tilit käytöstä samanaikaisesti — näin suljetaan aikaikkuna, jonka aikana orvoksi jääneitä tilejä voitaisiin käyttää hyväksi. SCIM täydentää SSO-protokollia (SAML/OIDC) käsittelemällä elinkaaren hallintaa, jota SSO-protokollat eivät kata.
Pikatarkistus
Testatkaa tämän oppitunnin CompTIA Security+ (SY0-701) -käsitteiden ymmärtämistä.
Oppitunnin yhteenveto
Tässä oppitunnissa opitte, että SAML 2.0 käyttää XML-väitteitä yritysten selainpohjaiseen SSO:hon; OAuth 2.0 on valtuutuskehys API-käytön delegointiin; OpenID Connect lisää OAuthin päälle todennuksen (JWT-ID-tunnukset); ja SCIM automatisoi identiteetin elinkaaren hallinnan federoitujen järjestelmien välillä. Tämä päättää Todennus ja valtuutus -kurssin — seuraavaksi käsittelemme verkkoturvallisuuden perusteita.
Opi Cloud & IT Cert Prep tekoälytuutorin avulla — ilmaiseksi
Kirjoita ja suorita oikeaa koodia selaimessa, saa välitöntä apua tekoälytuutorilta ympäri vuorokauden ja jatka siitä, mihin jäit, verkossa tai sovelluksessa.
- Kurssit
- 150
- Oppitunnit
- 600
Usein kysytyt kysymykset
Onko oppitunti ”Liittoutunut identiteetti: SAML, OAuth ja OpenID Connect” ilmainen?
Kyllä – oppitunnin ”Liittoutunut identiteetti: SAML, OAuth ja OpenID Connect” koko tekstin voi lukea täällä verkossa ilmaiseksi. Jos haluat harjoitella interaktiivisesti sisäänrakennetulla koodieditorilla ja ympäri vuorokauden käytettävissä olevan tekoälytuutorin avulla sekä avata koko Cloud & IT Cert Prep-kurssin, päivitä CoddyKit PROhon. Cloud & IT Cert Prep-kurssilla on yhteensä 4 oppituntia.
Mitä opin oppitunnilla ”Liittoutunut identiteetti: SAML, OAuth ja OpenID Connect”?
Oppikaa, miten SSO, SAML-väitteet, OAuth 2.0 -kulut ja OpenID Connect -tokenit mahdollistavat käyttäjien turvallisen kertatunnistautumisen useissa sovelluksissa. Harjoittelet Cloud & IT Cert Prep-aihetta koodilla, jonka suoritat suoraan selaimessa. Ympäri vuorokauden käytettävissä oleva tekoälytuutori vastaa kysymyksiisi oppitunnin aikana.
Tarvitsenko kokemusta aloittaakseni Cloud & IT Cert Prep-opiskelun?
Aiempi kokemus ei ole tarpeen. CoddyKitin Cloud & IT Cert Prep-oppimispolku sopii vasta-alkajista edistyneisiin, joten voit aloittaa tästä tai alusta ja edetä omaan tahtiisi. Tämä on oppitunti 4/4.
Kuinka kauan ”Liittoutunut identiteetti: SAML, OAuth ja OpenID Connect”-oppitunnin suorittaminen kestää?
Useimmat CoddyKitin oppitunnit kestävät noin 5–10 minuuttia. Jokainen oppitunti on lyhyt ja interaktiivinen, joten edistyt tasaisesti ja voit jatkaa siitä, mihin jäit – sekä verkossa että sovelluksessa.
Voinko kirjoittaa ja suorittaa koodia tällä Cloud & IT Cert Prep-oppitunnilla?
Kyllä. Jokainen Cloud & IT Cert Prep-oppitunti sisältää sisäänrakennetun koodieditorin, joten voit kirjoittaa ja suorittaa oikeaa koodia suoraan selaimessa ja saada välitöntä palautetta tekoälyltä – paikallista asennusta ei tarvita.
Kaikki tämän kurssin oppitunnit
- Salasanakäytännöt ja monivaiheinen tunnistautuminen
- Biometria ja tunnistautuminen tokeneilla
- Valtuutusmallit: RBAC, MAC ja DAC
- Liittoutunut identiteetti: SAML, OAuth ja OpenID Connect