Veilig inloggen

De aanbevolen manier voor ontwikkelaars om bij Git in te loggen is HTTPS + Git Credential Manager (GCM): interactief inloggen via de IdP van je organisatie, met MFA bij elke tokenvernieuwing. SSH staat bij nieuwe fremforge-organisaties standaard uit; ervaren ontwikkelaars die specifiek SSH nodig hebben, kunnen de beheerder van hun organisatie vragen het weer aan te zetten. Deze pagina behandelt de inrichting van GCM voor macOS, Linux en Windows, plus een onderdeel met alternatieven: SSH en PAT’s.

Waarom HTTPS + GCM de standaard is

GCM is de opensource-credential-helper van Microsoft; fremforge integreert ermee via de ingebouwde OAuth2-provider van Forgejo. Werkt op ontwikkelwerkstations met Windows, macOS en Linux.

HTTPS + Git Credential Manager (aanbevolen)

Stap 1: GCM installeren

# macOS via Homebrew
brew install --cask git-credential-manager

# Linux (Debian/Ubuntu, Fedora, etc. — see GCM repo for distro-specific paths)
curl -sL https://aka.ms/gcm/linux-install-source.sh | sh
git-credential-manager configure

# Windows — bundled with Git for Windows 2.28+ (re-installer prompt offers GCM)

Stap 2: GCM configureren voor fremforge

Voer dit eenmalig per werkstation uit:

# Tell GCM to use the Forgejo/Gitea OAuth provider for frem.sh URLs.
git config --global credential.https://frem.sh.gitProvider gitea

# Use fremforge's pre-registered Git Credential Manager OAuth application.
# Same client_id across every fremforge org — your sign-in still goes
# through your org's own IdP (the per-tenant OIDC source registered at
# /<your-org>/_admin/sso).
git config --global credential.https://frem.sh.oauthClientId e90ee53c-94e2-48ac-9358-a874fb9e0662

De OAuth-applicatie is de ingebouwde git-credential-manager-client die met Forgejo wordt meegeleverd: registratie per instantie is niet nodig; dezelfde client-ID werkt tegen elke fremforge-instantie en elke Git-host op basis van Forgejo. De client gebruikt PKCE (Proof Key for Code Exchange), dus er is geen client_secret nodig op de machine van de ontwikkelaar. De loopback-callbacks (http://127.0.0.1, http://localhost) worden op elke poort geaccepteerd, volgens RFC 8252 §7.3.

Stap 3: Clonen via HTTPS

git clone https://frem.sh/<your-org>/<your-repo>.git

GCM opent een browsertabblad → frem.sh vraagt om je e-mailadres (zodat we weten bij welke organisatie je hoort) → stuurt je door naar de inlogpagina van jouw organisatie → alleen de IdP-knop(pen) van jouw organisatie worden getoond → je voert wachtwoord + MFA in bij je IdP → de browser keert terug naar GCM → token in de cache. De IdP’s van andere organisaties zijn nooit zichtbaar. Volgende clones, fetches en pushes binnen de levensduur van het token verlopen stil.

Toegangstokens zijn 24 uur geldig; binnen die periode verloopt elke git push stil. Vernieuwingstokens zijn 30 dagen geldig, dus de eerste push nadat het toegangstoken is verlopen, vernieuwt het zonder browservenster. Elke machine waarop je inlogt, houdt haar eigen werkende inlog, dus git gebruiken op een laptop en een desktop (of in WSL) dwingt geen van beide om opnieuw in te loggen. Na 30 dagen zonder push of fetch opent de volgende weer de browser en vraagt je IdP om MFA.

Als GCM de browser opent om opnieuw in te loggen (een nieuw apparaat, nadat je bent uitgelogd, of na 30 dagen zonder gebruik), vraagt frem.sh je eerst met je authenticator-app of beveiligingssleutel te bevestigen dat jij het bent. Dat is ongeveer één keer per maand op elk apparaat; het vernieuwen van de aanmelding op de achtergrond vraagt er nooit om. Zie Waarom moet ik bevestigen dat ik het ben?

Stap 4 (optioneel): verstandige standaardinstellingen instellen

# Cache the OAuth token between sessions instead of re-running the
# browser flow every laptop reboot. GCM stores it in the OS keychain
# (macOS Keychain / Windows Credential Manager / Linux libsecret).
git config --global credential.credentialStore gpg     # Linux only
git config --global credential.guiPrompt true          # macOS / Linux

Alternatieven

Persoonlijk toegangstoken (alleen voor CI-bots en scripts)

PAT’s zijn statische bearer-tokens zonder MFA. Ze zijn prima voor onbeheerde automatisering, maar nooit voor pushes door mensen.

# 1. Mint at frem.sh/user/settings/applications
# 2. Set expiry to the shortest practical value (30 days for routine,
#    90 days for stable CI). If your org admin has set a max lifetime
#    policy, the mint page caps the dropdown automatically.
# 3. Use as the password for HTTPS clone:
git clone https://<your-username>:<pat>@frem.sh/<org>/<repo>.git

# Or via GCM's "store in keychain" path so you don't bake it into URLs:
git -c credential.helper=store clone https://frem.sh/<org>/<repo>.git
# Enter username + paste PAT when prompted; cached in ~/.git-credentials.

OIDC-tokens van Forgejo Actions (workloadidentiteit voor CI, geen statische inloggegevens)

Gebruik voor CI/CD die naar AWS, Azure, GCP of T Cloud Public deployt bij voorkeur gefedereerde identiteit in plaats van PAT’s. fremforge geeft CI-jobs kortlevende OIDC-tokens van zijn runner-OIDC-uitgever, https://frem.sh/_app/runner/oidc (discovery op https://frem.sh/_app/runner/oidc/.well-known/openid-configuration); stel de IAM van je cloudprovider zo in dat die deze uitgever vertrouwt. De claims (sub, aud, repository_owner) staan op de pagina hieronder. Zie Runner-OIDC voor de sjablonen van het vertrouwensbeleid per cloud.

SSH (alleen als de beheerder van je organisatie het uitdrukkelijk heeft aangezet)

Nieuwe fremforge-organisaties hebben SSH standaard uitgeschakeld. Heeft je organisatie SSH nodig (verouderde CI, een sterke voorkeur van ontwikkelaars voor de werkwijze met SSH-sleutels):

1. De beheerder van de organisatie gaat naar <your-org>/_admin/auth-policy en vinkt “SSH-protocol toestaan” aan, en accepteert daarmee de gedocumenteerde beperking dat de IP-allowlist niet voor SSH geldt.
2. Leden voegen SSH-sleutels toe op frem.sh/user/settings/keys en configureren hun ~/.ssh/config:

Host frem.sh
    Hostname ssh.frem.sh
    Port 443
    IdentityFile ~/.ssh/id_ed25519

3. Gebruik waar mogelijk sleutels met hardwarebescherming (ssh-add --apple-use-keychain op macOS voor Touch ID; ssh-keygen -t ed25519-sk voor FIDO/YubiKey op Linux). Zie het onderdeel over SSH-sleutels met hardwarebescherming hieronder.

Je eigen OAuth-applicaties: vraag expliciet om scopes

Registreer je een OAuth2-applicatie op frem.sh (Instellingen van gebruiker of organisatie › Applicaties) om mensen te laten inloggen of om namens hen de API aan te roepen, dan kan het token alleen doen wat de aangevraagde scopes toestaan:

• API-scopes (read:repository, write:issue, read:user en de rest): het token werkt zoals voorheen op de API en op Git via HTTPS, binnen die scopes.
• Alleen openid, profile, email, groups: het token laat de persoon inloggen en verder niets. Het werkt op /login/oauth/userinfo en /login/oauth/introspect en krijgt 401 op de API, de pakketregisters en Git.
• Helemaal geen scope: hetzelfde, alleen inloggen. Alleen de eigen clients van fremforge (Git Credential Manager, zoals hierboven geconfigureerd, en de fremforge-CLI) houden zonder scope volledige toegang.

Een applicatie die de API nodig heeft, moet dus in de parameter scope van /login/oauth/authorize om de API-scopes vragen die ze nodig heeft. Heeft ze al een toestemming met een andere scope, dan trekt de persoon die in onder Geautoriseerde OAuth2 applicaties op frem.sh/user/settings/applications en logt opnieuw in.

SSH-sleutels met hardwarebescherming (voor organisaties die SSH weer hebben aangezet)

Heeft de beheerder van je organisatie SSH weer aangezet en heb je het echt nodig, dan zijn sleutels met hardwarebescherming de dringend aanbevolen praktijk. Het organisatiebeleid “Require hardware-backed SSH keys” weigert bij het registreren elke sleutel die niet tot de algoritmefamilie sk-* behoort.

macOS: Secure Enclave

ssh-keygen -t ed25519 -C "your-name@your-org" -f ~/.ssh/id_ed25519
ssh-add --apple-use-keychain ~/.ssh/id_ed25519

Touch ID vraagt bij elke push om bevestiging als de macOS-sleutelhanger de sleutel niet onlangs heeft ontgrendeld. Voor een sleutel die volledig in de Secure Enclave leeft (aangemaakt en bewaard binnen de chip), gebruik je Secretive.

Linux: YubiKey of FIDO-authenticator

ssh-keygen -t ed25519-sk -C "your-name@your-org" -f ~/.ssh/id_ed25519_sk
ssh-add ~/.ssh/id_ed25519_sk

Vereist OpenSSH 8.2+ (februari 2020) voor ed25519-sk; op oudere distributies is ecdsa-sk het alternatief.

Windows: TPM-beschermd via WSL2 of KeePassXC

De ingebouwde OpenSSH van Windows biedt geen directe toegang tot de TPM. Twee routes:

1. WSL2: volg de Linux-werkwijze binnen WSL2.
2. KeePassXC- of 1Password-SSH-agent: beide bewaren sleutels die zijn beschermd door de biometrie van Windows Hello.

Beslisboom

Are you a human developer pushing code daily?
├── Yes → HTTPS + GCM (the recommended default; no SSH key needed)
│         ├── If your org has re-enabled SSH and you prefer it → hardware-backed SSH key
│         └── If you specifically need a static credential → PAT with 30-day expiry
└── No, I'm a CI bot or script
    ├── Cloud-deploying → Forgejo Actions OIDC token (no static cred)
    └── Other → PAT with tight scope + short expiry

Wat je NIET moet doen

• Langlevende PAT’s in git-configuratiebestanden of .netrc. Statische bearer-tokens zonder vervaldatum zijn het slechtste authenticatiepatroon. Gebruik GCM voor mensen, OIDC-tokens voor CI en PAT’s met een korte geldigheid voor verouderde bots.
• Een kale ssh-keygen -t ed25519 zonder hardwarebescherming of eis van de organisatie. De sleutel staat in ~/.ssh/; laptop kwijt = sleutel gecompromitteerd, zolang de sleutel bestaat.
• MFA omzeilen met patronen als “SSH-sleutel altijd vertrouwen”. Heeft je organisatie handhaving op het niveau van een IP-allowlist nodig, dan betekent dat HTTPS: de IP-allowlist van fremforge werkt realtime op HTTPS en is architectonisch niet mogelijk op SSH.
• SSH weer aanzetten omdat “het sneller is”. Het verschil in inrichtingsmoeite is na de eerste dag verwaarloosbaar; het verschil in beveiliging is reëel.

Referentie voor beheerders van de organisatie

Ben je eigenaar van een organisatie en stel je beleid in:

• Beheerhandleiding authenticatiebeleid: de schakelaar om SSH uit te zetten, de eis voor SSH-sleutels met hardwarebescherming, de SSH-certificaatautoriteit (samengevoegd op 2026-05-26), de maximale levensduur van PAT’s, de schakelaar allow repo deploy keys, ondertekende commits, het bereik van de IP-allowlist en de voorvertoning in alleen-auditmodus