Skip to content

Commit 74c0d47

Browse files
committed
wip
1 parent 3d9b529 commit 74c0d47

File tree

1 file changed

+60
-2
lines changed

1 file changed

+60
-2
lines changed

content/extensions/ui-extensions.md

Lines changed: 60 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -197,13 +197,71 @@ To configure an `iframe` UI extension, mandatory fields are `name`, `position`,
197197

198198
**Ensuring security of embedded iframes**
199199

200-
- Properly configure [Content Security Policy (CSP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) headers to control the sources from which content can be loaded.
200+
* Properly configure [Content Security Policy (CSP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) headers to control the sources from which content can be loaded.
201201

202202
::: warning
203203
Please note that if these headers are misconfigured, iframe functionality may not work as intended.
204204
:::
205205

206-
- Add a secret to you extension. It will be used to generate a JWT token that is sent to the iframe using post message.
206+
* Add a secret to your extension. This secret will be used to generate a JWT token when the iframe is loaded by the PIM system.
207+
208+
**Receiving the JWT Token via ```postMessage```**
209+
210+
Upon loading the iframe, the PIM will send a postMessage with the JWT token. The message will be structured as follows:
211+
212+
```json
213+
{
214+
"type": "JWT_TOKEN"
215+
"token": "jwt_value"
216+
}
217+
```
218+
219+
* The JWT token in the token field is generated using SHA256 encryption based on the secret you provided.
220+
221+
For more information on how JWT tokens are structured and used, you can refer to the associated [RFC 7519](https://datatracker.ietf.org/doc/html/rfc7519).
222+
223+
**JWT Token Structure**
224+
225+
The JWT token consists of three main parts: the header, the body (payload), and the signature.
226+
227+
*Header*
228+
229+
* The header typically contains information about the token type and the signing algorithm. In this case, it will look like:
230+
231+
```json
232+
{
233+
"typ": "JWT",
234+
"alg": "HS256"
235+
}
236+
```
237+
238+
*Payload*
239+
240+
* The payload contains the claims. The JWT token’s will look like this:
241+
242+
```json
243+
{
244+
"jti": "c1b6b9f1-8486-4f9e-9f96-8d1b40fccb65",
245+
"iat": 1743410036.116152,
246+
"exp": 1743413636.116162,
247+
"userId": "1"
248+
}
249+
```
250+
251+
* jti: The unique identifier for the token.
252+
* iat: The issued at time.
253+
* exp: The expiration time of the token.
254+
* userId: The PIM user identifier (in this case, 1).
255+
256+
*A signature*
257+
258+
* The signature is used to verify that the token is valid and has not been tampered with. It is generated by combining the encoded header and payload, and then signing them with the secret key. The resulting signature might look like:
259+
```9WBB7ayP8UnFrOlMrI9NzTj3kxaiXOWJzElyacEKt48```
260+
261+
**Verifying the Signature**
262+
263+
To ensure that the JWT token was issued by Akeneo, you can verify the signature by re-encoding the header and payload and then signing them using the same secret key. This will allow you to confirm that the token is valid and has not been altered.
264+
207265

208266
**PostMessage**
209267

0 commit comments

Comments
 (0)