You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The redirect request is a HTTP GET request which is used to redirect the user back to the return address entered upon registration of the client application in [eeID manager](https://eeid.ee). In the redirect request an authorization code is sent to the client application, based on which the client application will request the access token in order to get personal identification code, name and other attributes of the authenticated person. The security code state received in the authentication request is mirrored back. Read more about forming and verifying state from [Protection against false request attacks](#protection).
The client secret code must be provided in the identity token request. For this purpose, the request must include the `Authorization` request header with the value formed of the word Basic, a space and a string `<client_id>:<client_secret>` encoded in the Base64 format. The body of the HTTP POST request must be presented in a serialised [format](https://openid.net/specs/openid-connect-core-1_0.html#FormSerialization) based on the OpenID Connect protocol. The body of the request must include the `code` received from the authentication service.
438
+
There are two supported client authentication modes for token request:
do not send client secret, send `client_id` and `code_verifier` in request body.
444
+
445
+
The body of the HTTP POST request must be presented in a serialised [format](https://openid.net/specs/openid-connect-core-1_0.html#FormSerialization) based on the OpenID Connect protocol. The body of the request must include the `code` received from the authentication service.
424
446
425
447
The body of the request must include the following parameters:
426
448
@@ -429,6 +451,25 @@ Element | Description
429
451
`grant_type` | The `authorization_code` value required based on the protocol
430
452
`code` | The authorization code received from the authentication service
431
453
`redirect_uri`| The redirect URL sent in the authorisation request
454
+
`client_id` | Required for public PKCE clients
455
+
`code_verifier` | Required for public PKCE clients. Must match the `code_challenge` sent in the auth request
456
+
457
+
PKCE/public client token request example:
458
+
459
+
```shell
460
+
POST https://auth.eeid.ee/hydra-public/oauth2/token
PKCE requirement follows OAuth2 Authorization Code + PKCE best practices. For flow details and rationale, see Ory documentation: [OAuth2 authorization code flow](https://www.ory.com/docs/oauth2-oidc/authorization-code-flow).
432
473
433
474
The server verifies that the identity token is requested by the right application and issues the identity token included in the response body. The response body uses JSON format consisting four elements:
434
475
@@ -550,6 +591,41 @@ about the error are returned:
550
591
}
551
592
```
552
593
594
+
## PKCE (Proof Key for Code Exchange)
595
+
596
+
[PKCE](https://datatracker.ietf.org/doc/html/rfc7636) is a security extension for OAuth2 Authorization Code flow. It protects public clients (for example SPA, mobile app, desktop app) from authorization code interception attacks.
597
+
598
+
In PKCE flow, the client:
599
+
600
+
1. Generates a random `code_verifier`
601
+
2. Calculates `code_challenge` from that verifier using SHA-256 (`S256`)
602
+
3. Sends `code_challenge` in authorization request (`/oauth2/auth`)
603
+
4. Sends original `code_verifier` in token request (`/oauth2/token`)
604
+
605
+
The authorization server validates that `code_verifier` matches the original `code_challenge`. If it does not match, token issuance fails.
606
+
607
+
### Which mode to choose in eeID Manager
608
+
609
+
- Use `token_endpoint_auth_method=none` for public PKCE clients.
610
+
- Use `token_endpoint_auth_method=client_secret_basic` for confidential server-side clients that can safely store a client secret.
- For PKCE/public clients, do not send client secret.
624
+
625
+
### Why this matters
626
+
627
+
Without PKCE, a stolen authorization code can be exchanged for tokens by an attacker. PKCE binds the code exchange to the same client that initiated the login flow.
628
+
553
629
## Protection
554
630
555
631
The client application must implement protective measures against false request attacks (cross-site request forgery, CSRF).
0 commit comments