0.2.0-0-pre.3
This commit is contained in:
282
docs/studies/008-WEB_IDENTITY_AND_GAME_HOSTING_STUDY.md
Normal file
282
docs/studies/008-WEB_IDENTITY_AND_GAME_HOSTING_STUDY.md
Normal file
@@ -0,0 +1,282 @@
|
||||
<!-- file: docs/studies/008-WEB_IDENTITY_AND_GAME_HOSTING_STUDY.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Étude Web, identité et hébergement des jeux
|
||||
|
||||
## Statut
|
||||
|
||||
Étude non normative pour `0.2.0-0-pre.3`.
|
||||
|
||||
## Objectif
|
||||
|
||||
Permettre un démarrage simple sous une plateforme commune puis une évolution vers des sites et services propres à certains jeux sans casser l'identité joueur.
|
||||
|
||||
## Identité canonique
|
||||
|
||||
Le backend games.sasedev doit posséder un identifiant joueur canonique indépendant des providers externes.
|
||||
|
||||
Conceptuellement :
|
||||
|
||||
```text
|
||||
PlayerId
|
||||
├─ anonymous device identity
|
||||
├─ email/password ou passwordless
|
||||
├─ Google identity
|
||||
├─ Apple identity
|
||||
├─ Play Games identity
|
||||
├─ Steam identity
|
||||
└─ autres providers futurs
|
||||
```
|
||||
|
||||
Un provider externe est une identité liée, pas la clé primaire du joueur.
|
||||
|
||||
## Modes d'authentification à prévoir
|
||||
|
||||
### Anonymous
|
||||
|
||||
Cas :
|
||||
|
||||
- découverte immédiate du jeu ;
|
||||
- première partie sans création de compte ;
|
||||
- fonctionnement offline ou semi-online.
|
||||
|
||||
Doit permettre si nécessaire :
|
||||
|
||||
- création d'un profil temporaire ;
|
||||
- migration vers un compte durable ;
|
||||
- conservation de progression lors de l'upgrade.
|
||||
|
||||
### Credentials propres
|
||||
|
||||
Options à étudier :
|
||||
|
||||
- email + mot de passe ;
|
||||
- username + mot de passe ;
|
||||
- magic link ;
|
||||
- passkey/WebAuthn.
|
||||
|
||||
Le choix final dépendra des besoins sécurité/UX.
|
||||
|
||||
### OAuth / OpenID Connect
|
||||
|
||||
Providers plausibles :
|
||||
|
||||
- Google ;
|
||||
- Apple ;
|
||||
- autres comptes sociaux si pertinents.
|
||||
|
||||
Le backend doit valider les tokens/provider claims puis lier l'identité externe à son `PlayerId`.
|
||||
|
||||
### Platform identities
|
||||
|
||||
Exemples :
|
||||
|
||||
- Google Play Games ;
|
||||
- Apple Game Center ;
|
||||
- Steam.
|
||||
|
||||
Ces identités peuvent faciliter sign-in, achievements ou leaderboard mais ne remplacent pas l'identité canonique globale.
|
||||
|
||||
## Account linking
|
||||
|
||||
Cas à prévoir :
|
||||
|
||||
- anonymous → compte durable ;
|
||||
- Google + Apple sur le même joueur ;
|
||||
- appareil perdu puis récupération ;
|
||||
- changement de provider ;
|
||||
- conflit lorsque deux providers correspondent déjà à deux comptes distincts.
|
||||
|
||||
Le merge de comptes doit être explicite et sécurisé.
|
||||
|
||||
## Sessions
|
||||
|
||||
Besoins :
|
||||
|
||||
- access token court ;
|
||||
- refresh/session token ;
|
||||
- révocation ;
|
||||
- liste des devices/sessions éventuellement ;
|
||||
- logout global ou local ;
|
||||
- rotation ;
|
||||
- protection CSRF/cookies pour Web selon architecture ;
|
||||
- stockage sécurisé côté apps natives.
|
||||
|
||||
Le détail cryptographique sera étudié séparément avant implémentation.
|
||||
|
||||
## Portail initial
|
||||
|
||||
Déploiement initial plausible :
|
||||
|
||||
```text
|
||||
games.sasedev.com
|
||||
```
|
||||
|
||||
Responsabilités possibles :
|
||||
|
||||
- catalogue ;
|
||||
- login/signup ;
|
||||
- compte joueur ;
|
||||
- pages des jeux ;
|
||||
- leaderboards ;
|
||||
- support ;
|
||||
- liens vers stores ;
|
||||
- jeu Web pour les produits compatibles ;
|
||||
- administration séparée.
|
||||
|
||||
Les premiers jeux peuvent être servis sous :
|
||||
|
||||
```text
|
||||
games.sasedev.com/games/snake
|
||||
games.sasedev.com/games/reflex
|
||||
```
|
||||
|
||||
ou équivalent.
|
||||
|
||||
Le chemin exact n'est pas encore décidé.
|
||||
|
||||
## Évolution vers un site propre
|
||||
|
||||
Un jeu devenu suffisamment important peut avoir :
|
||||
|
||||
```text
|
||||
snake.example-game-domain.tld
|
||||
```
|
||||
|
||||
ou un domaine propre.
|
||||
|
||||
Le déplacement ne doit pas imposer :
|
||||
|
||||
- nouveau compte joueur ;
|
||||
- nouvelle base d'identité ;
|
||||
- duplication des providers OAuth ;
|
||||
- incompatibilité des leaderboards/progression.
|
||||
|
||||
Le site propre consomme les services communs via des APIs versionnées.
|
||||
|
||||
## Sous-services
|
||||
|
||||
Découpage logique candidat :
|
||||
|
||||
```text
|
||||
www.games.sasedev.com
|
||||
auth.games.sasedev.com
|
||||
api.games.sasedev.com
|
||||
cdn.games.sasedev.com
|
||||
leaderboard.games.sasedev.com
|
||||
realtime.games.sasedev.com
|
||||
admin.games.sasedev.com
|
||||
```
|
||||
|
||||
et, pour un jeu spécifique :
|
||||
|
||||
```text
|
||||
www.<game-domain>
|
||||
api.<game-domain>
|
||||
realtime.<game-domain>
|
||||
cdn.<game-domain>
|
||||
```
|
||||
|
||||
Ce sont des frontières logiques possibles, pas une obligation de créer immédiatement tous ces DNS/process.
|
||||
|
||||
## Global vs game-specific
|
||||
|
||||
Services globalement partageables :
|
||||
|
||||
- auth/identity ;
|
||||
- account/profile ;
|
||||
- entitlement général éventuel ;
|
||||
- catalogue ;
|
||||
- administration centrale ;
|
||||
- common CDN assets éventuels.
|
||||
|
||||
Services souvent game-specific :
|
||||
|
||||
- gameplay API ;
|
||||
- matchmaking ;
|
||||
- realtime simulation ;
|
||||
- rulesets ;
|
||||
- game inventory/progression spécialisée ;
|
||||
- events/seasons ;
|
||||
- maps/assets propres au jeu.
|
||||
|
||||
Certains services, comme leaderboard, peuvent avoir une API générique et une configuration par jeu.
|
||||
|
||||
## Multi-tenant logique
|
||||
|
||||
Le backend commun doit pouvoir distinguer :
|
||||
|
||||
- `game_id` ;
|
||||
- environment ;
|
||||
- protocol/version ;
|
||||
- player ;
|
||||
- product/platform.
|
||||
|
||||
Éviter de dupliquer tout le backend par jeu avant qu'une isolation réelle ne soit nécessaire.
|
||||
|
||||
## Hébergement et découpage physique
|
||||
|
||||
Étape initiale plausible :
|
||||
|
||||
```text
|
||||
modular monolith
|
||||
```
|
||||
|
||||
avec modules clairement séparés.
|
||||
|
||||
Évolution possible :
|
||||
|
||||
```text
|
||||
auth service
|
||||
API service
|
||||
realtime service
|
||||
leaderboard service
|
||||
game-specific services
|
||||
```
|
||||
|
||||
La séparation physique est motivée par :
|
||||
|
||||
- charge ;
|
||||
- sécurité ;
|
||||
- cycle de déploiement ;
|
||||
- isolation de panne ;
|
||||
- besoins réseau ;
|
||||
- ownership.
|
||||
|
||||
Pas par recherche de microservices pour eux-mêmes.
|
||||
|
||||
## Web game hosting
|
||||
|
||||
Un jeu Web/WASM peut être :
|
||||
|
||||
- servi directement par le portail global ;
|
||||
- servi par son propre site ;
|
||||
- embarqué dans une page Tauri pour certains produits ;
|
||||
- télécharger ses assets depuis un CDN séparé.
|
||||
|
||||
Le build jeu doit rester indépendant du hostname final.
|
||||
|
||||
## CORS / origins / OAuth redirects
|
||||
|
||||
Le passage d'un domaine global à des domaines propres impose de prévoir :
|
||||
|
||||
- origins autorisées ;
|
||||
- callback URLs OAuth ;
|
||||
- cookies/domain policy ;
|
||||
- CORS ;
|
||||
- CSP ;
|
||||
- token audience ;
|
||||
- deep links/app links éventuels.
|
||||
|
||||
Ces points doivent être configurables et non hardcodés dans le gameplay.
|
||||
|
||||
## Questions ouvertes
|
||||
|
||||
- quel provider d'identité implémenter en premier ?
|
||||
- anonymous account server-side dès le début ou seulement local ?
|
||||
- email/password, magic link ou passkey ?
|
||||
- cookies de session pour Web vs bearer tokens pour apps natives ?
|
||||
- comment gérer account merge ?
|
||||
- quel découpage initial entre portail, auth, API et realtime ?
|
||||
- quels services doivent être multi-game dès V1 ?
|
||||
- comment versionner les APIs et protocoles par jeu ?
|
||||
Reference in New Issue
Block a user