Autentisering och auktorisering

I företagsappar är säkerheten avgörande! Vi behöver veta vem som använder appen och vad personen får göra.

Den här lektionen behandlar autentisering (verifiering av identitet) och auktorisering (beviljande av åtkomst).

Autentisering är processen att bekräfta en användares identitet. Se det som att bevisa att Ni är den Ni säger Er vara.

• Vanliga metoder: Användarnamn och lösenord, biometri (Face ID/Touch ID), säkerhetstoken.
• En lyckad autentisering innebär att systemet litar på användarens identitet.

När användaren har autentiserats avgör auktorisering vilka åtgärder användaren får utföra och vilka data personen får komma åt.

• En användare med rollen "admin" kan till exempel se alla rapporter, medan en "regular"-användare bara ser sina egna.
• Det handlar om behörigheter, inte om identitet.

Efter autentiseringen utfärdar servrar ofta en token (som en digital nyckel) till appen. Denna token skickas sedan med efterföljande förfrågningar.

Tokenar bär identitets- och auktoriseringsinformation på ett säkert sätt, så att användaren inte behöver autentiseras på nytt för varje åtgärd.

OAuth 2.0 är ett branschstandardprotokoll för delegerad auktorisering. Det låter användare ge webbplatser eller applikationer åtkomst till deras information på andra webbplatser utan att lämna ut sitt lösenord.

• Det är INTE självt ett autentiseringsprotokoll, men används ofta tillsammans med OpenID Connect (OIDC) för autentisering.
• Det används ofta för funktioner som "Log in with Google/Facebook".

För att förstå OAuth 2.0 behöver Ni känna till fyra viktiga roller:

• Resource Owner: Användaren som äger informationen (Ni!).
• Client: Applikationen som begär åtkomst (Er mobilapp).
• Authorization Server: Verifierar resursägarens identitet och utfärdar åtkomsttokenar.
• Resource Server: Lagrar skyddade data och resurser och accepterar åtkomsttokenar.

För mobilappar är Authorization Code Flow with PKCE (Proof Key for Code Exchange) den säkraste grant-typen i OAuth 2.0.

• Appen omdirigerar användaren till Authorization Server.
• Användaren loggar in och beviljar behörighet.
• Authorization Server skickar tillbaka en auktoriseringskod till appen.
• Appen byter koden mot en åtkomsttoken (och ofta även en refresh token).

iOS tillhandahåller ramverk som förenklar integreringen av OAuth 2.0, särskilt för extern webbaserad autentisering:

• SFSafariViewController: Visar webbinnehåll i appen och delar cookies med Safari.
• ASWebAuthenticationSession: Ett modernare och säkrare sätt att autentisera användare via webbtjänster, med automatisk hantering av omdirigeringar och delning av autentiseringstillstånd.

Dessa förhindrar att appen hanterar känsliga användaruppgifter direkt.

Single Sign-On (SSO) låter användare autentisera sig en gång och få åtkomst till flera fristående programvarusystem utan att autentisera sig igen.

• Det är avgörande i företagsmiljöer för produktivitet och säkerhet.
• Exempel: Logga in i alla företagets appar med företagets inloggningsuppgifter (till exempel Active Directory, Okta och Azure AD).

Integrering av SSO i Objective-C-appar innebär ofta användning av företagsidentitetsleverantörer (IdP:er) som stöder standarder som SAML eller OpenID Connect (OIDC).

• Många IdP:er tillhandahåller SDK:er för iOS för att förenkla integreringen.
• Appen omdirigerar vanligtvis till en företagsinloggningssida (ofta i en säker webbvyn) och tar sedan emot en token efter lyckad autentisering.

Ni har lärt Er de viktiga skillnaderna mellan autentisering (vem Ni är) och auktorisering (vad Ni får göra).

Vi behandlade OAuth 2.0 för delegerad auktorisering och dess viktigaste komponenter, inklusive den säkra Authorization Code Flow för mobila enheter.

Slutligen utforskade vi Single Sign-On (SSO) för förenklad åtkomst till företagssystem i Objective-C-appar.