FR
RU
EN
ES
ZH
DE
PT
AR
HI
Introduction : pourquoi l'autorisation est-elle nécessaire dans les applications mobiles ?
Les applications iOS modernes fonctionnent rarement de manière isolée. Elles communiquent avec des serveurs, envoient des données, reçoivent du contenu personnalisé. Mais comment le serveur peut-il savoir que la requête a été envoyée par l'utilisateur qu'il prétend être ? C'est là que OAuth 2.0 et JWT (JSON Web Token) viennent à la rescousse. Ce ne sont pas seulement des abréviations à la mode, mais des normes de sécurité qui sont à la base du fonctionnement de la plupart des API modernes (Google, Facebook, GitHub, votre propre backend).
Dans cet article, nous allons voir comment fonctionnent OAuth 2.0 et JWT sur Swift. Vous apprendrez en quoi ils diffèrent, comment les implémenter correctement et quels pièges attendent le débutant. Nous écrirons du code pour obtenir, stocker et renouveler les jetons. C'est parti !
1. Les bases : OAuth 2.0 et JWT — quelle est la différence ?
Beaucoup confondent ces deux concepts. En réalité, ce sont des niveaux d'abstraction différents.
- OAuth 2.0 est un protocole d'autorisation. Il décrit comment une application (client) peut accéder aux ressources d'un utilisateur sur un serveur tiers (par exemple, ses photos sur Google) sans transmettre de nom d'utilisateur ni de mot de passe. L'idée principale est la délivrance de jetons d'accès temporaires.
- JWT est un format de jeton. C'est une chaîne compacte et sûre pour les URL qui contient des données JSON (par exemple, l'ID de l'utilisateur, le rôle, la date d'expiration) et une signature. JWT est souvent utilisé comme jeton d'accès dans OAuth 2.0, mais peut également être utilisé séparément.
Une analogie simple : OAuth 2.0 correspond aux règles de délivrance d'un laissez-passer pour un stade, tandis que JWT est le laissez-passer en plastique lui-même avec votre photo et un cachet.
Dans un scénario typique, une application iOS :
- Ouvre un navigateur pour se connecter via un fournisseur OAuth (Google, Apple ID, son propre serveur).
- Obtient un code d'autorisation.
- Échange le code contre un jeton d'accès (souvent au format JWT) et un jeton d'actualisation.
- Utilise le jeton d'accès pour les requêtes vers l'API.
- Lorsque le jeton d'accès expire, utilise le jeton d'actualisation pour en obtenir un nouveau.
2. Structure d'un jeton JWT
Un JWT se compose de trois parties séparées par des points :
header.payload.signatureExemple d'un JWT décodé :
// Header (en-tête){ "alg": "HS256", "typ": "JWT"}// Payload (charge utile){ "sub": "1234567890", "name": "Ivan Petrov", "iat": 1516239022, "exp": 1516242622}// Signature (signature) - créée par le serveurImportant : Le payload d'un JWT n'est pas chiffré, il est seulement encodé en Base64. N'importe qui peut le lire. La confidentialité est assurée par la signature — si le serveur constate que la signature ne correspond pas, il rejette le jeton. Par conséquent, ne stockez jamais de mots de passe ou de données secrètes dans un JWT.
3. Implémentation d'OAuth 2.0 et JWT sur Swift
Passons maintenant à la pratique. Nous allons écrire une classe pour gérer l'autorisation. Pour simplifier, nous utiliserons l'URLSession intégrée, bien que dans les projets réels on utilise souvent Alamofire ou SwiftUI + async/await.
3.1. Modèles de données
struct AuthResponse: Codable { let accessToken: String let refreshToken: String? let expiresIn: Int enum CodingKeys: String, CodingKey { case accessToken = "access_token" case refreshToken = "refresh_token" case expiresIn = "expires_in" }}
struct UserProfile: Codable { let id: String let name: String let email: String}3.2. Service d'autorisation
Créons une classe AuthService qui sera responsable de l'obtention et du renouvellement des jetons. Attention : dans une application réelle, l'URL et le clientSecret doivent être stockés de manière sécurisée (par exemple, dans Keychain ou via un serveur de configuration).
class AuthService { static let shared = A 
