Authorization Code Flow

The Authorization Code flow is the main integration method for L’Identité Numérique La Poste.

It allows partners to:

• authenticate a user
• retrieve identity data
• ensure a high level of security

The flow is based on a multi-step exchange:

1. User redirection to LINLP
2. Authentication (mobile)
3. Return with a temporary code
4. Exchange the code for tokens
5. Retrieve user data

👉 This flow complies with the OpenID Connect standard.

The partner redirects the user to LINLP.

GET /authorize

Main parameters:

• client_id
• redirect_uri
• response_type=code
• scope
• state (recommended)
• nonce (recommended)
• login_hint (optional)

Example:

https://authent.pprod.lidentitenumerique.laposte.fr/auth/realms/partenaire/protocol/openid-connect/auth
?client_id=XXX
&response_type=code
&redirect_uri=https://myservice.com/callback
&scope=openid+profile+email
&state=abc123
&nonce=xyz456

💡 `login_hint` can be used to prefill the user’s phone number.

The user:

• is redirected to LINLP
• receives a notification on their mobile device
• validates using their secret PIN code

👉 Data consent is requested when required.

After success:

https://myservice.com/callback?code=ABC123&state=abc123

⚠️ The code:

• is temporary (short lifetime)
• is single-use

The backend calls:

POST /token

Example:

grant_type=authorization_code
code=ABC123
redirect_uri=https://myservice.com/callback

👉 Authentication is required through:

• client_id
• client_secret

Response:

• access_token
• id_token (signed JWT)
• expires_in

GET /userinfo
Authorization: Bearer access_token

👉 Returns:

• user data (claims)
• contextual information

⚠️ The partner must retain the id_token

👉 Why?

• it constitutes the proof of user authentication
• it is signed by LINLP
• it can be cryptographically verified at any time
• it does not depend on LINLP availability

👉 Use cases:

• login audit trail
• legal proof
• post-event verification
• dispute management

💡 Unlike the access_token, the id_token should be retained by the partner

⚠️ Always use a backend

• Never call `/token` from the frontend.

⚠️ Validate the state parameter

• Prevents CSRF attacks.

⚠️ Validate the nonce

• Prevents replay attacks.

⚠️ Verify the id_token signature

• Ensures data integrity.

⚠️ Handle expirations

• Codes and tokens expire quickly.

⚠️ Log errors

• Essential for support and debugging.

⚠️ redirect_uri must match exactly

• Otherwise the request is rejected.

⚠️ Scopes must be declared in advance

• They cannot be added dynamically.

⚠️ The flow is synchronous for the user

• Plan an appropriate UX (loading, waiting screens).

⚠️ Returned data depends on:

• requested scopes
• LINLP configuration
• user consent

• Standard OpenID Connect flow
• Based on redirection + secure token exchange
• Returns tokens including the key id_token
• Recommended for all web and mobile use cases

👉 For advanced use cases:

CIBA Flow