Todentaminen ja valtuutus

Yrityssovelluksissa tietoturva on avainasemassa! Meidän on tiedettävä, kuka sovellusta käyttää ja mitä hän voi tehdä.

Tässä oppitunnissa käsitellään autentikointia (henkilöllisyyden varmistamista) ja valtuutusta (käyttöoikeuksien myöntämistä).

Autentikointi on prosessi, jossa käyttäjän henkilöllisyys vahvistetaan. Ajatelkaa sitä sen todistamisena, että olette se henkilö, joka väitätte olevanne.

• Yleisiä menetelmiä: Käyttäjätunnus ja salasana, biometriset tunnisteet (Face ID/Touch ID) sekä suojaustunnisteet.
• Onnistunut autentikointi tarkoittaa, että järjestelmä luottaa käyttäjän henkilöllisyyteen.

Kun käyttäjä on autentikoitu, valtuutus määrittää, mitä toimintoja hän saa suorittaa tai mitä tietoja hän saa käyttää.

• Esimerkiksi "admin"-käyttäjä voi tarkastella kaikkia raportteja, kun taas "regular"-käyttäjä näkee vain omansa.
• Kyse on käyttöoikeuksista, ei henkilöllisyydestä.

Autentikoinnin jälkeen palvelimet myöntävät sovellukselle usein tunnisteen (digitaalisen avaimen kaltaisen). Tunniste lähetetään myöhempien pyyntöjen mukana.

Tunnisteet välittävät henkilöllisyys- ja valtuutustietoja turvallisesti, joten käyttäjää ei tarvitse autentikoida uudelleen jokaisen toiminnon yhteydessä.

OAuth 2.0 on alan standardiprotokolla delegoidulle valtuutukselle. Sen avulla käyttäjät voivat myöntää verkkosivustoille tai sovelluksille pääsyn toisilla sivustoilla oleviin tietoihinsa luovuttamatta salasanaansa.

• Se EI itsessään ole autentikointiprotokolla, mutta sitä käytetään usein yhdessä OpenID Connectin (OIDC) kanssa autentikointiin.
• Sitä käytetään yleisesti "Kirjaudu Googlella/Facebookilla" -toiminnoissa.

OAuth 2.0:n ymmärtämiseen kuuluu neljä keskeistä roolia:

• Resource Owner: Käyttäjä, joka omistaa tiedot (eli te!).
• Client: Pääsyä pyytävä sovellus (mobiilisovelluksenne).
• Authorization Server: Varmistaa resource ownerin henkilöllisyyden ja myöntää access tokenit.
• Resource Server: Säilyttää suojatut tiedot/resurssit ja hyväksyy access tokenit.

Mobiilisovelluksissa Authorization Code Flow with PKCE (Proof Key for Code Exchange) on turvallisin OAuth 2.0 -grant-tyyppi.

• Sovellus ohjaa käyttäjän Authorization Serverille.
• Käyttäjä kirjautuu sisään ja myöntää luvan.
• Authorization Server lähettää authorization coden takaisin sovellukselle.
• Sovellus vaihtaa coden access tokeniin (ja usein myös refresh tokeniin).

iOS tarjoaa kehyksiä OAuth 2.0 -integraation yksinkertaistamiseen erityisesti ulkoista verkkopohjaista autentikointia varten:

• SFSafariViewController: Verkkosisällön näyttämiseen sovelluksen sisällä ja evästeiden jakamiseen Safarin kanssa.
• ASWebAuthenticationSession: Nykyaikaisempi ja turvallisempi tapa autentikoida käyttäjiä verkkopalvelujen kautta; se käsittelee uudelleenohjaukset automaattisesti ja jakaa autentikointitilan.

Näin sovelluksen ei tarvitse käsitellä arkaluonteisia käyttäjätunnistetietoja suoraan.

Single Sign-On (SSO) antaa käyttäjille mahdollisuuden autentikoitua kerran ja käyttää useita toisistaan riippumattomia ohjelmistojärjestelmiä ilman uutta autentikointia.

• Se on yritysympäristöissä tärkeää tuottavuuden ja tietoturvan kannalta.
• Esimerkkejä: kirjautuminen kaikkiin yrityksen sovelluksiin yrityksen tunnistetiedoilla (esimerkiksi Active Directory, Okta tai Azure AD).

SSO:n integrointi Objective-C-sovelluksiin tarkoittaa usein sellaisten yritysten identiteetintarjoajien (IdP) käyttöä, jotka tukevat standardeja, kuten SAMLia tai OpenID Connectia (OIDC).

• Monet IdP:t tarjoavat iOS:lle SDK:ita integroinnin helpottamiseksi.
• Sovellus ohjaa käyttäjän yleensä yrityksen kirjautumissivulle (usein suojatussa web-näkymässä) ja vastaanottaa tunnisteen onnistuneen autentikoinnin jälkeen.

Olette oppineet keskeisen eron autentikoinnin (kuka olette) ja valtuutuksen (mitä voitte tehdä) välillä.

Käsittelimme OAuth 2.0:aa delegoituun valtuutukseen ja sen keskeisiä komponentteja, kuten mobiililaitteille turvallista Authorization Code -kulkua.

Lopuksi tarkastelimme Single Sign-Onia (SSO) yrityskäytön sujuvoittamiseen Objective-C-sovelluksissa.