# MitID Associate Flow

This describes the end-to-end flow for MitID first-time association, from Bright down to SonWinCommonAPI.

## 1. Citizen authenticates with MitID (Bright's job, not ours)

Bright Gateway runs the full MitID OIDC login in the browser/app. By the time this is done, Bright knows the person's MitID identity (a GUID) and their claimed first/last name.

## 2. First-time linking — Bright calls EG Common

Since this is a brand-new MitID identity, Bright also asks the user for their existing customer number + PIN code, then calls:

```
POST /subscriptions/{subscriptionId}/mitid/associate
{ ref, customerId, pinCode, firstName, lastName }
```

## 3. EG Common — thin proxy, no logic of its own

Looks up which backend this subscription uses (SonWin), forwards the request as-is to SonWin's `auth/mitid/associate`, using its own service-to-service bearer token. Nothing is transformed — the field names match end-to-end.

## 4. SonWinCommonAPI — the real work happens here

- Looks up the customer by `customerId` + `pinCode`. Wrong pair → reject (customer/PIN invalid).
- Each customer has two name slots (`NAVN1`/`NAVN2` — e.g. a couple sharing an account). If neither slot has a MitID yet, it matches the given first/last name against both to figure out *which* person is linking → no match → reject (name mismatch).
- If a slot already has some MitID, it checks whether *this exact* MitID is already registered → if so, reject (already registered).
- Otherwise: **inserts a new row into `Sonlinc.AMITID`**, permanently linking that MitID GUID to that customer's name slot.
- Returns the matched customer's number + name.

## 5. Response flows back up

SonWin's success/failure is turned into an internal status by EG Common, then translated into a plain HTTP response for Bright — success returns `200 OK` (no body — Bright already has the identity, it just needed the link confirmed); failures come back as `400`/`401`/`404` depending on what went wrong.

## One deliberate exclusion

Subsequent logins (returning users) are **not** part of this flow at all — Bright's own database is now the source of truth for "have I seen this MitID before," so it never calls back into SonWin for that. This associate flow only ever runs once per person, the first time they link MitID to their account.