Authentication and Authorization

In enterprise apps, security is key! We need to know who is using the app and what they can do.

This lesson covers authentication (verifying identity) and authorization (granting access).

Authentication is the process of confirming a user's identity. Think of it as proving you are who you say you are.

• Common methods: Username/password, biometrics (Face ID/Touch ID), security tokens.
• A successful authentication means the system trusts the user's identity.

Once authenticated, authorization determines what actions a user is allowed to perform or what data they can access.

• For example, an "admin" user might view all reports, while a "regular" user only sees their own.
• It's about permissions, not identity.

After authentication, servers often issue a token (like a digital key) to the app. This token is then sent with subsequent requests.

Tokens securely carry identity and authorization information, avoiding the need to re-authenticate for every action.

OAuth 2.0 is an industry-standard protocol for delegated authorization. It lets users grant websites or applications access to their information on other sites, without giving away their password.

• It's NOT an authentication protocol itself, but often used in conjunction with OpenID Connect (OIDC) for authentication.
• Commonly used for "Log in with Google/Facebook" features.

Understanding OAuth 2.0 involves four key roles:

• Resource Owner: The user who owns the data (you!).
• Client: The application requesting access (your mobile app).
• Authorization Server: Verifies the resource owner's identity and issues access tokens.
• Resource Server: Holds the protected data/resources and accepts access tokens.

For mobile apps, the Authorization Code Flow with PKCE (Proof Key for Code Exchange) is the most secure OAuth 2.0 grant type.

• The app redirects the user to the Authorization Server.
• User logs in, grants permission.
• Authorization Server sends an authorization code back to the app.
• App exchanges the code for an access token (and often a refresh token).

iOS provides frameworks to simplify OAuth 2.0 integration, specifically for external web authentication:

• SFSafariViewController: For displaying web content within your app, sharing cookies with Safari.
• ASWebAuthenticationSession: A more modern, secure way to authenticate users through web services, automatically handling redirects and sharing authentication state.

These prevent your app from directly handling sensitive user credentials.

Single Sign-On (SSO) allows users to authenticate once and gain access to multiple independent software systems without re-authenticating.

• Crucial in enterprise environments for productivity and security.
• Examples: Logging into all company apps with your corporate credentials (e.g., Active Directory, Okta, Azure AD).

Integrating SSO with Objective-C apps often involves using enterprise identity providers (IdPs) that support standards like SAML or OpenID Connect (OIDC).

• Many IdPs provide SDKs for iOS to simplify the integration.
• The app typically redirects to an enterprise login page (often in a secure web view), then receives a token upon successful authentication.

Let's check your understanding of authentication and authorization.

You've learned about the critical differences between authentication (who you are) and authorization (what you can do).

We covered OAuth 2.0 for delegated authorization and its key components, including the secure Authorization Code Flow for mobile.

Finally, we explored Single Sign-On (SSO) for streamlined enterprise access in Objective-C apps.