API-autentikointi: OAuth vs API key vs Basic Auth

Miksi autentikointi tarvitaan?

API on palvelun "takaovi" jota ohjelmat käyttävät. Ilman autentikointia kuka tahansa voisi lukea tai muuttaa dataasi. Autentikointi varmistaa:

• Kuka pyytää: Onko pyyntö oikealta taholta
• Mitä saa tehdä: Lukea, kirjoittaa, poistaa?
• Rajoitukset: Montako pyyntöä saa tehdä (rate limiting)

Vertailu

Tapa	Turvallisuus	Monimutkaisuus	Käyttötapaus
API Key	Kohtalainen	Helppo	Palvelin-palvelin
OAuth 2.0	Korkea	Monimutkainen	Käyttäjän puolesta toimiminen
Basic Auth	Matala	Helppo	Vanhat järjestelmät

API Key

API key on pitkä satunnainen merkkijono joka toimii "salasanana". Saat sen palvelun asetuksista ja lähetät sen joka pyynnössä.

# Headerissa (yleisempi)
Authorization: Bearer sk_live_abc123xyz

# Tai query-parametrina (ei suositella)
https://api.example.com/data?api_key=sk_live_abc123xyz

Plussat

• Helppo toteuttaa ja testata
• Ei monimutkaista token-hallintaa
• Riittää useimpiin palvelin-palvelin-integraatioihin

Miinukset

• Jos avain vuotaa, pääsy koko tiliin
• Avain ei vanhene automaattisesti
• Ei sovi käyttäjän puolesta toimimiseen

OAuth 2.0

OAuth on standardi jossa käyttäjä antaa sovellukselle luvan toimia puolestaan. Esimerkki: "Salli sovelluksen lukea Google-kalenterisi."

Tyypillinen OAuth-flow (Authorization Code)

1. Käyttäjä ohjataan palvelun kirjautumissivulle
2. Käyttäjä kirjautuu ja hyväksyy oikeudet
3. Palvelu palauttaa authorization coden
4. Sovellus vaihtaa coden access tokeniin
5. Access tokenia käytetään API-kutsuissa
6. Token vanhenee → refresh tokenilla haetaan uusi

Plussat

• Käyttäjän salasana ei mene sovellukselle
• Rajatut oikeudet (scopet)
• Token vanhenee → pienempi vahinkoriski

Miinukset

• Monimutkaisempi toteuttaa
• Vaatii token-hallintaa (refresh)
• Overkill jos ei tarvita käyttäjän puolesta toimimista

Basic Auth

Basic Auth lähettää käyttäjätunnuksen ja salasanan joka pyynnössä, Base64-koodattuna.

# Header
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

# Base64("username:password")

Plussat

• Erittäin helppo toteuttaa
• Laajasti tuettu

Miinukset

• Base64 ei ole salaus – vaatii HTTPS:n
• Salasana liikkuu joka pyynnössä
• Vanhentunut käytäntö, käytä mieluiten API keytä

Mikä sopii integraatioosi?

• Palvelin-palvelin (esim. CRM → laskutus): API key riittää
• Käyttäjän puolesta (esim. Google Calendar): OAuth 2.0
• Vanha järjestelmä joka ei tue muuta: Basic Auth + HTTPS

Avainten turvallinen säilytys

• Ei koodiin: Älä koskaan commitoi avaimia Gitiin
• Ympäristömuuttujat: .env-tiedosto jota ei commitoida
• Secrets manager: AWS Secrets Manager, Azure Key Vault
• Rajoita oikeudet: Vain tarvittavat toiminnot, ei admin-oikeuksia
• Kierrätä säännöllisesti: Vaihda avaimet vähintään vuosittain

Yleiset virheet

1. Avain GitHubissa: Botit skannaavat ja käyttävät vuotaneita avaimia minuuteissa.
2. HTTP ilman S:ää: Avain liikkuu selkokielisenä verkossa.
3. Liian laajat oikeudet: "Full access" kun riittäisi "read only".
4. Ei uusita: Sama avain käytössä vuosia, vaikka työntekijöitä vaihtunut.
5. Ei monitoroida: Et tiedä jos avaimellasi tehdään outoja kutsuja.

Usein kysytyt kysymykset

Mistä saan API keyn?

Palvelun asetuksista tai developer-portaalista. Usein: Asetukset → API / Integraatiot → Luo avain. Joissain palveluissa pitää pyytää erikseen.

Mitä teen jos avain vuotaa?

Poista avain heti käytöstä palvelun asetuksista. Luo uusi avain ja päivitä integraatioon. Tarkista lokeista mitä avaimella on tehty.

Voiko OAuth:ia käyttää ilman käyttäjän kirjautumista?

Kyllä, OAuth:in "Client Credentials" -flow on suunniteltu palvelin-palvelin-käyttöön. Mutta useimmiten API key on yksinkertaisempi vaihtoehto samaan tarpeeseen.

Lue myös

• Webhookit käytännössä
• Integraatioprojektin speksi
• Tietoturvan peruspaketti
• Integraatiot ja automaatio palveluna →