Miksi tuotteesi tarvitsee OAuth 2.0:aa ja OIDC:ta — erityisesti AI-aikakaudella

Alusta alkaen Logto rakennettiin vahvalla uskolla avoimiin standardeihin. Päätimme seurata protokollia kuten OIDC, OAuth 2.0 ja SAML — ei vain siksi, että ne ovat laajasti käytössä, vaan koska ne edustavat vakiintuneita, turvallisia käytäntöjä, jotka ovat alan luotettuja. Turvallisuus on aina ollut meille etusijalla. Samoin pysyvä uskollisuus avoimen lähdekoodin hengelle ja parhaiden käytäntöjen noudattaminen asiakasidentiteetin hallinnassa ja nykyaikaisessa tunnistautumisessa.

Mutta opimme myös jotain matkan varrella:

OAuth 2.0 ja OIDC eivät ole helppoja kaikille. Kehittäjille, jotka ovat uusia näissä protokollissa, konseptit voivat tuntua vierailta ja joskus jopa vastoin intuitiota. Tämä johti todellisiin haasteisiin, kun pyrimme yksinkertaistamaan kehittäjäkokemusta vaarantamatta turvallisuutta.

Kaksi asiaa erottuivat:

1. Vaikka olemme tehneet kovasti työtä tehdäksemme integraatiosta mahdollisimman sujuvaa, on vielä oppimiskäyrä ymmärtää peruskäsitteitä kuten ID-tokeneita, käyttöoikeustokeneita ja kuinka ne toimivat.
2. Yleinen kysymys, jonka saamme, on: “Voinko ohittaa uudelleenohjauksen kirjautumisnäytössä?” Valitettavasti uudelleenohjaus on olennainen osa sitä, miten OIDC toimii ja on välttämätön turvalliselle tunnistautumiselle.

Yleinen kysymys Discord-käyttäjiltämme (heidän ID:t ja avatarit on peitetty yksityisyyden vuoksi).

Jokainen päätös sisältää kompromisseja — mutta joskus valinta, jonka teit varhain, osoittautuu erityisen arvokkaaksi, kun uusia käyttötarkoituksia syntyy. Ja nyt olemme astumassa uuteen aikakauteen: AI-aikakauteen.

Tässä artikkelissa pohdin, milloin tuotteesi tulisi käyttää OIDC:tä ja OAuth 2.0:aa, milloin se ei saata tarvita niitä, ja miksi olen aina puolustanut näiden avointen standardien omaksumista alusta alkaen — erityisesti jos rakennat todellista liiketoimintaa ja valitset CIAM-ratkaisun. Selitän myös, miksi AI:n nousu tekee tästä päätöksestä tärkeämmän kuin koskaan.

Mitä OAuth 2.0 todella tekee (yksinkertainen vertauskuva)#

Lukijoille, jotka eivät ole kovin tuttuja OAuth 2.0:sta, otan hetken käydäkseni läpi joitakin peruskäsitteitä uudelleen — vain selkeyttääkseni asioita.

OAuth 2.0 on delegoitu valtuutus: OAuth 2.0 on teollisuusstandardi protokolla valtuutukselle – se sallii yhden palvelun käyttää resursseja toisen palvelun puolesta resurssin omistajan suostumuksella.

OAuth-tapauksessa käyttäjä (resurssin omistaja) antaa asiakassovellukselle rajoitetun pääsyn (rajatut oikeudet) API:lle tai resurssipalvelimelle jakamatta salasanaa. OAuth määrittelee, kuinka pyytää ja antaa käyttöoikeustokeneita, joita asiakas voi käyttää suojattujen API-kutsujen tekemiseen. Tämä oli merkittävä muutos verrattuna varhaisiin päiviin, jolloin sovellukset saattoivat pyytää tunnuksiasi päästäkseen toiseen palveluun (vakava turvallisuusriski). OAuth 2.0:lla käyttäjät hyväksyvät tietyn pääsyn ja asiakas saa tunnuksen vain tarvittavilla oikeuksilla ja kestolla — salasanoja ei vaihdeta, mikä parantaa merkittävästi turvallisuutta.

Ajattele OAuth 2.0:aa kuten hotellin sisäänkirjautumista.

Sinä (käyttäjä) olet huoneen omistaja (tietosi). Mutta sen sijaan, että antaisit avainkorttisi (salasanasi), menet vastaanottoon ja pyydät väliaikaista pääsykorttia (käyttöoikeustunnusta), joka toimii vain vieraallesi tai ystävällesi päästäksesi kuntosalille tai uima-altaaseen — ei koko huoneeseen.

Hotellin henkilökunta (OAuth-järjestelmä) antaa tämän rajatun kortin tietyillä säännöillä:

• Se toimii vain kuntosalille (tietyille resursseille).
• Se on voimassa vain lyhyen aikaa.
• Se ei salli kenenkään päästä huoneeseesi.

Tällä tavalla sinun ei tarvitse luovuttaa pääavainkorttiasi — ja järjestelmä pysyy turvallisena, vaikka joku saisi haltuunsa tämän rajatun kortin.

Katsotaanpa toista esimerkkiä. OAuth 2.0 on laajasti käytössä sosiaalisen kirjautumisen skenaariossa.

Sano, että kirjaudut uuteen sovellukseen, kuten Notion, ja sen sijaan, että loisit uuden käyttäjätunnuksen ja salasanan, napsautat “Jatka Googlella.”

Näin tapahtuu kulissien takana OAuth 2.0:n kanssa:

1. Sinut ohjataan Googlen kirjautumissivulle, jossa kirjaudut sisään (jos et vielä ole).

2. Google kysyy:

   “Sallitko tämän sovelluksen tarkastella perusprofiiliasi ja sähköpostiosoitettasi?”

3. Napsautat “Salli”, ja Google lähettää sovellukselle käyttöoikeustunnuksen.

4. Sovellus käyttää tätä tunnusta:

   • Vahvistamaan henkilöllisyytesi (sähköpostin ja profiilitietojesi kautta).
   • Luo tai kirjaa sinut tilille — koskaan näkemättä Google-salasanaasi.

Mitä OIDC todella tekee (yksinkertainen vertauskuva)#

Nyt tarkastellaan OIDC:tä — uudempaa ja kehittyneempää standardia. OpenID Connect keskittyy henkilöllisyyteen ja käyttäjän tunnistamiseen: se on tunnistautumiskerros rakennettuna OAuth 2.0:n päälle. Vaikka pelkkä OAuth 2.0 ei kerro sovellukselle, kuka käyttäjä on (se käsittelee vain käyttöoikeustokeneita ja laajuuksia), OIDC lisää standardin tavan käsitellä käyttäjän kirjautumista ja henkilöllisyyttä. 

Kun käytät OIDC:tä, valtuutuspalvelin toimii myös OpenID-palveluntarjoajana (Identiteettipalveluntarjoajana), joka tunnistaa käyttäjän ja antaa ID-tokenin, joka sisältää tietoja käyttäjästä ("identiteettiväitteet").

Lyhyesti sanottuna OAuth 2.0 vastaa kysymykseen “Voiko tämä asiakas käyttää tätä resurssia?” ja OIDC vastaa kysymykseen “Kuka käyttäjä juuri kirjautui sisään?”. Yhdessä ne antavat sovelluksellesi mahdollisuuden tunnistaa käyttäjän identiteetti ja käyttää valtuutettuja tokeneita API:hin käyttäjän puolesta.

Käytetään hotellivertausta ymmärtääksemme OAuth 2.0 vs. OIDC uudelleen.

Kuvittele, että olet kirjautumassa hotelliin.

• OAuth 2.0 on kuin pyytäisit hotellilta, että ystäväsi voisi käyttää kuntosalia ja uima-allasta puolestasi.

  Menet vastaanottoon, annat luvan, ja hotelli antaa ystävällesi vieraskortin.

  Hotellia ei kiinnosta kuka ystävä on — vain että hänellä on lupa käyttää tiloja.

  👉 Tätä on OAuth: “Tämä sovellus voi käyttää joitain tietojani tai palveluitani.”

• OIDC on kuin pyytäisit hotellia tarkistamaan kuka henkilö on ennen kuin hänelle annetaan pääsy.

  Joten ystäväsi näyttää myös henkilöllisyystodistusta — ja nyt hotelli tietää hänen nimensä, asemansa ja että hän on vahvistettu asiakas.

  👉 Tätä on OIDC: “Tässä on kuka käyttäjä on, ja hän on nyt kirjautunut sisään.”

Kuinka Logto käyttää OAuth 2.0:aa ja OpenID Connectiä (OIDC)#

Logton ydin autentikointiominaisuudet on rakennettu OIDC:n (OpenID Connect) päälle#

Pohjimmiltaan, Logto on OpenID Connect (OIDC) -palveluntarjoaja — standardi, joka on rakennettu OAuth 2.0:n päälle ja keskittyy turvalliseen, nykyaikaiseen käyttäjän tunnistautumiseen. Logto on ammattimainen CIAM-ratkaisu, jossa identiteetti on ydin, jota hallitsemme.

Olemme suunnitelleet Logton turvallisuus perustana. Tämä tarkoittaa, että PKCE on pakotettu oletuksena, estää epävarmat virrat kuten implisiittivirta, ja luottaa uudelleenohjaukseen käsitelläksesi kirjautumisia turvallisesti.

Miksi uudelleenohjaus?#

OIDC on tarkoitettu selaimenpohjaiseen tunnistautumiseen. Se ei ole vain tekninen valinta — kyse on käyttäjille turvallisen, yhtenäisen kokemuksen tarjoamisesta eri alustoilla. Uudelleenohjaamalla käyttäjä identiteettipalveluntarjoajalle (kuten Logto, Google tai Microsoft) auttaa tekemään sen mahdolliseksi.

Tässä on miltä tyypillinen virta näyttää:

1. Käyttäjä napsauttaa “Kirjaudu sisään”

   → Sovelluksesi ohjaa heidät Logton kirjautumissivulle.

2. He kirjautuvat sisään turvallisesti

   → Tässä tapahtuu asioita kuten MFA, biometriset tunnisteet tai sosiaalinen kirjautuminen.

3. Logto ohjaa heidät takaisin

   → Yhdessä turvallisen tunnuksen tai valtuutuskoodin kanssa.

4. Sovelluksesi suorittaa kirjautumisen

   → Tunnus tarkistetaan, ja käyttäjä kirjautuu sisään.

Tämä malli saattaa tuntua yksinkertaiselta, mutta se tuo voimakkaita etuja:

• Sovelluksesi ei käsittele tunnuksia suoraan — mikä tarkoittaa vähemmän riskejä.
• On helpompaa lisätä ominaisuuksia, kuten MFA, muuttamatta sovelluskoodia.
• Se toimii loistavasti myös mobiililaitteille:
  • iOS käyttää ASWebAuthenticationSession
  • Android käyttää Custom Tabs

Ja jos tuotteesi kattaa useita sovelluksia, Uudelleenohjaus mahdollistaa yksinkertaisen kirjautumisen — käyttäjät kirjautuvat sisään kerran, ja siirtyvät sovellusten välillä vaivattomasti.

Logto ei tue salasanojen keräämistä suoraan sovelluksessasi. Se on tarkoituksellista. ROPC-virta ei ole suositeltava OAuth 2.0:n turvallisuuden parhaiden käytäntöjen vuoksi — se on vähemmän turvallinen ja vaikeampi skaalata turvallisesti.

Logto on myös OAuth 2.0/OIDC-palveluntarjoaja (Identiteettipalveluntarjoaja)#

Logto on enemmän kuin pelkkä tunnistautumispalvelin — se on täysi OAuth 2.0, OpenID Connect (OIDC) ja Identiteettipalveluntarjoaja (IdP). Tämä tarkoittaa, että se voi hallita turvallisesti käyttäjäidentiteettejä ja antaa tunnuksia, joihin muut sovellukset voivat luottaa.

Lisäksi Logto tukee kolmannen osapuolen sovellusten integrointeja, sallimalla ulkopuolisten palvelujen luottaa Logtoon heidän identiteetin lähteenään.

Mitä tämä tarkoittaa käytännössä?

Identiteettipalveluntarjoajana (IdP) Logto hoitaa käyttäjän vahvistamisen, hallitsee tunnuksia ja antaa todennustunnuksia. Kun käyttäjä on kirjautunut sisään, Logto voi antaa heille pääsyn eri sovelluksiin — jopa muiden toimittajien — ilman uudelleen kirjautumista. Se on sama konsepti kuin “Kirjaudu Googlella” tai “Kirjaudu Microsoftilla”.

Tässä kontekstissa on kaksi sovellustyyppiä:

• Ensimmäisen osapuolen sovellukset: Sovelluksia, joita kehitit ja joita hallitset täysin, integroitu suoraan Logtoon.
• Kolmannen osapuolen sovellukset: Ulkopuolisten kumppaneiden tai kehittäjien rakentamia palveluja.

Logto mahdollistaa käyttäjilleen kirjautumisen näihin kolmannen osapuolen sovelluksiin käyttäen olemassa olevia Logto-tilejä — aivan kuten yrityskäyttäjät kirjautuvat työkaluihin kuten Slack Google Workspacen tunnuksilla. Tämä mahdollistaa:

• Tarjoa yksinkertainen kirjautuminen (SSO) ekosysteemissäsi.
• Rakenna avoin alusta, johon kolmannen osapuolen kehittäjät voivat lisätä “kirjautumisen Logtolla” sovelluksiinsa.

Milloin tarvitset todella OAuth 2.0 ja OIDC:tä?#

1. Jos olet aikaisemmin käyttänyt Auth0:aa (tai vastaavaa): Auth0 on jo OAuth 2.0 ja OIDC-palveluntarjoaja. Se hallitsee käyttäjien kirjautumista, tunnusten myöntämistä ja integroituu API:eisi tai sovelluksiisi.
2. Koneiden välinen valtuutus: palvelin-palvelin (asiakastunnustuksen virta) Koneet (tai taustapalvelut) tarvitsevat turvallisen viestinnän ilman käyttäjää.
3. Laitteen virta: Älytelevisiot, konsolit, IoT-laitteet: Laitteet kuten televisiot tai tulostimet tarvitsevat käyttäjän tunnistamisen. Laitteen virta on osa OIDC:tä.
4. Sinulla on integraatiotarpeita: Et vain tunnista käyttäjiä — luot ekosysteemin, jossa ulkoiset sovellukset, kumppanit tai agentit voivat integroitua alustasi kanssa ja käyttää käyttäjätietoja turvallisesti.

Miksi OAuth ja OIDC ovat tärkeämpiä kuin koskaan AI-aikakaudella#

AI-aikakaudella näemme lisääntyvän määrän uusia integraatio- ja pääsytarpeita — erityisesti alueilla kuten autonomiset agentit, älylaitteet ja järjestelmästä toiseen -viestintä. Nämä trendit tekevät OAuth 2.0:sta ja OIDC:stä tärkeämpiä kuin koskaan. Tässä muutamia esimerkkejä:

1. Etä-MCP-palvelimet

   Rakennat etä-MCP (Model Context Protocol) -palvelimen ja haluat kolmannen osapuolen agenttien yhdistyvän siihen. Näiden agenttien on saatava turvallinen pääsy pyytääkseen kontekstia, suorittaakseen toimia ja vaihtaakseen tietoja — ilman, että käyttäjän luottamus vaarantuu. OAuth tarjoaa mekanismin valtuutuksen delegointiin turvallisesti.

2. Tuotteesi avaaminen integraatioille

   Käytät omia liiketoimintapalveluitasi — kuten projektinhallintatyökalu tai asiakasalusta — ja haluat antaa muiden tuotteiden tai agenttien integroitua siihen. Se voi tarkoittaa tietojen noutamista, työnkulkujen käynnistämistä tai ominaisuuksien upottamista muihin ympäristöihin. OAuth 2.0/OIDC mahdollistaa hienorakeisen, tunnuspohjaisen pääsynhallinnan jakamatta käyttäjätunnuksia.

3. Oman agentin rakentaminen

   Luot AI-agentin tai -assistentin ja haluat sen vuorovaikuttavan muiden sovellusten ja MCP-palvelinten kanssa — aikatauluttaen kokouksia, lähettäen sähköposteja, päivittäen viestejä tai hakien tietoja. Nämä vaativat turvallista, varmennettua pääsyä kolmansien osapuolten palveluihin. OAuth 2.0 on tapa, jolla agenttisi valtuutetaan toimimaan käyttäjän puolesta.

4. Älylaitteiden nousu

   Laitteiston, kuten AI-kääntäjien tai älykkäiden kokousmuistion tekijöiden, kyvyt kasvavat LLM:ien ansiosta. Ja alhaisemmat kustannukset ja parempi suorituskyky tekevät siitä, että enemmän näitä laitteita tulee markkinoille. Näiden laitteiden on usein löydettävä tapa tunnistaa käyttäjiä ja päästä pilvipohjaisiin palveluihin — erityisesti rajoitettujen syöttöliittymien kanssa. Tässä OAuth:in laitteen valtuutusvirta ja OIDC-pohjainen identiteetin validointi tulevat kriittisiksi.

Kun et ehkä tarvitse OAuth 2.0:aa/OIDC:tä#

Tietenkin on tapauksia, joissa et ehkä tarvitse OAuth 2.0:aa tai OIDC:tä — ainakaan ei nyt. Toisin sanoen, jos nykyinen käyttötapauksesi on yksinkertainen tai täysin itseään tukevampi, nämä protokollat ​​eivät ehkä tuo välitöntä arvoa.

Kuitenkin, kun tuotteesi kasvaa tai ekosysteemisi laajenee, tarve OAuth 2.0:lle ja OIDC:lle tulee usein paljon näkyvämmäksi pitkällä aikavälillä.

1. Yksinkertaiset sisäiset sovellukset

   Jos sovellustasi käyttää vain pienehkö tiimi yrityksen sisällä eikä sen tarvitse integroitua kolmannen osapuolen palveluihin tai altistaa API:eja, yksinkertainen käyttäjätunnus-salasana-aukko (esim., evästekokoukset) saattaa riittää.

2. Ei käyttäjän tunnistautumista tarvita

   Jos tuotteellasi ei ole käyttäjätunnuksia tai identiteettitietoisia ominaisuuksia — kuten julkinen sisältösivusto tai palvelin-palvelin -työkalu staattisilla API-avaimilla — OIDC:lle ei ole tarvetta.

3. Ei delegoitua pääsyä tarvita

   OAuth loistaa, kun tarvitset käyttäjiä valtuuttaaksesi sovelluksesi pääsemään heidän tietoihinsa toisessa järjestelmässä (esim., Google Drive). Jos et integroitu kolmannen osapuolen API-je kanssa tai rakenna monipalvelu työnkulkuja, OAuth lisää monimutkaisuutta vähäisellä arvolla.

4. Yksittäinen ympäristö, minimaalinen riski

   Varausvaiheen prototyypit, MVP:t tai sisäiset testityökalut, joissa yksinkertaisuus ja nopeus ovat turvallisuus tarpeiden yläpuolella, saatat viivästää OAuth/OIDC:n toteutusta myöhemmäksi.

Viimeiset ajatukset oikean tunnistusstrategian valinnasta#

Et ehkä tarvitse OAuth 2.0:aa tai OIDC:tä heti — ja se on täysin okei. Alkupisteissä yksinkertaiset ratkaisut saavat usein työn tehtyä. Mutta kun tuotteesi kasvaa, agentit ja AI integroituvat enemmän siihen, kuinka rakennamme, ja ekosysteemisi avautuu kumppaneille ja kolmansille osapuolille, turvallinen ja standardoitu tunnistautuminen muuttuu vähemmän mukavasta hyvästä ja enemmän pakolliseksi.

Sen sijaan, että yrittäisit pysyä mukana myöhemmin, kannattaa laittaa perusta nyt. OAuth 2.0:n ja OIDC:n hyväksyminen ei ole pelkästään tämän päivän ongelmien ratkaisua — se on valmiina siihen, mitä on tulossa seuraavaksi.