Attributes in the JWT of the access token

[gis-uam]

Good afternoon: Sorry for including this topic, but I've been trying to solve this issue for a few weeks and I can't find it. My intention is to add another attribute (besides sub) in the JWT of the access token. I have been looking at the documentation and as far as I understand, you have to create a filter in the file module_oidc.php in section:

'authproc.oidc' => [ ] I have tried with core:AttributeAdde and core:AttributeMap and in no case can I get the attribute defined in this section to be included in the jwt payload. Any suggestions? Thank you so much

[cicnavi]

Hi,

why would you want to add another claim in Access Token, what is your use case? The thing is, the spec doesn't mandate for the Access Token to be JWT, so I'm wondering why you need to do it.

Besides that, there is no way to hook into Access Token creation, it is basically hardcoded. What you did with authproc filters was altering user attributes...

Best regards

[gis-uam]

We have a simplesamlphp server (1.19.4) in which we have installed the simplesamlphp-module-oidc module We establish the entire protocol for obtaining the token. When making the request to /module.php/oidc/token.php I receive a token in jwt format like this: {"id_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiIsImtpZCI6IjhjNTlmNjZlMDdhZjU2YWE3OTQ3MjYzMDI4NDVhMDcxIn0.eyJpc3MiOiJodHRwczovL2Nhcy1wcmUudWFtLmVzIiwiaWF0IjoxNjg1OTc0NTk0LCJqdGkiOiIyZWI3NThhNjAyZDMzYmYyNmFiNGI5ZTVjNjA4MWVkODI4OGQyNTcxYmYyMWU5M2M2NTEwZmVkODRiNmM1M2E1MmQ5ZWIyN2MzYjE3NGU0OCIsImF1ZCI6Il83N2ZlOWY2MGYzYTNjNWIwZmFmMTE4MmNlM2NkMmViMmUwMWQyYjU4NWQiLCJuYmYiOjE2ODU5NzQ1OTQsImV4cCI6MTY4NTk3ODE5NCwic3ViIjoiSmltZW5leiIsImF0X2hhc2giOiJCWGZmeHh0QjhrMi1JNi1jS1R6MmxnIiwic2lkIjoiNmQ1ZTZiNGM2NjNjNDZjYmEyYjAxYzgwODI3ZTAwZTYiLCJhcHBjcnVlX2NuIjoiam1hcmlhLmdhcmNpYUBlc3R1ZGlhbnRlLnVhbS5lcyIsImFwcGNydWVfY29kUGVyc29uYSI6IjEwNjY0NCIsImFwcGNydWVfY29kTmlhIjoiODk0NzQiLCJhcHBjcnVlX25vbWJyZSI6Ikpvc2UgTWFyaWEiLCJhcHBjcnVlX2FwZWxsaWRvMSI6IkdhcmNpYSIsImFwcGNydWVfYXBlbGxpZG8yIjoiSmltZW5leiIsImFwcGNydWVfdGlwb2RvY3VtZW50byI6Im5vIiwiYXBwY3J1ZV9udW1kb2N1bWVudG8iOiIxMTgxMjg4MkoiLCJuYW1lMiI6Ikpvc2UgTWFyaWEiLCJuYXRpb25hbF9kb2N1bWVudF9pZCI6IjExODEyODgySiIsIm5pYSI6Ijg5NDc0IiwibmFtZSI6Ikpvc2UgTWFyaWEiLCJmYW1pbHlfbmFtZSI6IkdhcmNpYSIsImdpdmVuX25hbWUiOiJKaW1lbmV6Iiwibmlja25hbWUiOiJHYXJjaWEiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiIxMTgxMjg4MkoiLCJwcm9maWxlIjoiMTA2NjQ0IiwicGljdHVyZSI6Ijg5NDc0IiwiZW1haWwiOiJqbWFyaWEuZ2FyY2lhQGVzdHVkaWFudGUudWFtLmVzIiwiZW1haWxfdmVyaWZpZWQiOmZhbHNlfQ.DBeXkuiqUc7gT8JOJKJ275awKuFjGZCbftalx5xxxxx","token_type":"Bearer","expires_in":3600,"access_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJhdWQiOiJfNzdmZTlmNjBmM2EzYzViMGZhZjExODJjZTNjZDJlYjJlMDFkMmI1ODVkIiwianRpIjoiMmViNzU4YTYwMmQzM2JmMjZhYjRiOWU1YzYwODFlZDgyODhkMjU3MWJmMjFlOTNjNjUxMGZlZDg0YjZjNTNhNTJkOWViMjdjM2IxNzRlNDgiLCJpYXQiOjE2ODU5NzQ1OTQuMDU3MjM1LCJuYmYiOjE2ODU5NzQ1OTQuMDU3MjM5LCJleHAiOjE2ODU5NzgxOTQuMDUwNzI4LCJzdWIiOiI4OTQ3NCIsInNjb3BlcyI6WyJvcGVuaWQiLCJhcHBjcnVlIiwicHJvZmlsZSIsImVtYWlsIl19.PcPI6aZdi-et4rLSNEeJcj5lvkCsuKQInAeqwzNjHPH0kDuyKe_oxvUW8ggQLc7-N8zoRerKcpj5nBozJxAekBnX-5ck3knpw4Q_Md-V7TaD_uKuRMjf7quuvaagvGhsjbZqV6P7uwyvbfsV2DHp30ZfhqNmM83N7KlbBRH1FsgbP4DbLcURhJHnUPa2YeV-tsWXJ2hJjoRLseIGBJVrG6gfAQWPStB1-T9Yj-f3Q3OzO1Urz_j14hu-VbDjEZzWZ0dC_FyR8J_gLIl5wvNMLhPk3O0xTlobQ4gzpi1Oy7AFxCDEg2SZIOdrJC_ibFoi5Jt1tAKgWy3-JEVHtQxxxx","refresh_token":"def50200fbf59a5f419cfc0ff014cfc7cbea1ab2b0e76142abb4c92f61248bf798fc61a21a6a8ea58075860454c3d9ac2e71ab408b1ab4d3d2385d0c34b2fd3f48827ee58c45ba688d7750c8819facd2824dee8a3d49620f8ac37ebb825392b61be96284864e0f8464c667d866767122d8daff8b8e3acbb2dbaa4888db9f858301966ee1f785228d9e5a625f3e403618c6234fb34f397f90628f9194109acda6ef6b93af97c4d8d5f410f8680ea38ec0e4ecbf414a586d98457d030bb123c48ec46d36c14804a5f8b3ee95a273458c39ba947fe7f37688f999c1b931faaa9980026295f77642179829932177ba42aa83523baba3451ce13a5e98ac96cc6deac2aee9f259842ec1f60476d61aa49b4e2c0a9b460a6aa68661a8e1264d632796d46fb71e48906980be2b57cb1f8512319254ee1c341fee975d7d2ff65941329d2ebaa2860f13748ccb9c7752546366b67a0d56781f401e6458c9670ce0ca4b277a45f3e8a5421e3a1a4e5ed12241cf7ea993ec92cca4b90bff31f154ed69e187cc8ac38a374609a71dea992b0d849a3f57cbe3b95d3e9be02d11aab5ab077fe3f8534f7db303db26d702c6c9cb8f6bc69f678883XXXX"}

From the token received I extract the access token to perform the following accesses to the server access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJhdWQiOiJfNzdmZTlmNjBmM2EzYzViMGZhZjExODJjZTNjZDJlYjJlMDFkMmI1ODVkIiwianRpIjoiMmViNzU4YTYwMmQzM2JmMjZhYjRiOWU1YzYwODFlZDgyODhkMjU3MWJmMjFlOTNjNjUxMGZlZDg0YjZjNTNhNTJkOWViMjdjM2IxNzRlNDgiLCJpYXQiOjE2ODU5NzQ1OTQuMDU3MjM1LCJuYmYiOjE2ODU5NzQ1OTQuMDU3MjM5LCJleHAiOjE2ODU5NzgxOTQuMDUwNzI4LCJzdWIiOiI4OTQ3NCIsInNjb3BlcyI6WyJvcGVuaWQiLCJhcHBjcnVlIiwicHJvZmlsZSIsImVtYWlsIl19.PcPI6aZdi-et4rLSNEeJcj5lvkCsuKQInAeqwzNjHPH0kDuyKe_oxvUW8ggQLc7-N8zoRerKcpj5nBozJxAekBnX-5ck3knpw4Q_Md-V7TaD_uKuRMjf7quuvaagvGhsjbZqV6P7uwyvbfsV2DHp30ZfhqNmM83N7KlbBRH1FsgbP4DbLcURhJHnUPa2YeV-tsWXJ2hJjoRLseIGBJVrG6gfAQWPStB1-T9Yj-f3Q3OzO1Urz_j14hu-VbDjEZzWZ0dC_FyR8J_gLIl5wvNMLhPk3O0xTlobQ4gzpi1Oy7AFxCDEg2SZIOdrJC_ibFoi5Jt1tAKgWy3-JEVHtQXXXX

And if I decode it I get the JWT Header={"typ":"JWT","alg":"RS256"} Payload={"aud":"_77fe9f60f3a3c5b0faf1182ce3cd2eb2e01d2b585d","jti":"2eb758a602d33bf26ab4b9e5c6081ed8288d2571bf21e93c6510fed84b6c53a52d9eb27c3b174e48","iat":1685974594.057235,"nbf":1685974594.057239,"exp":1685978194.050728,"sub":"89474","scopes":["openid","appcrue","profile","email"]}

It is in this JWT token where, in addition to the iat, nbf, exp, sub and scope attributes, I wanted to include other user attributes without having to make another request to the server like so: /module.php/oidc/userinfo.php

It is in the original creation process where we want to include those extra attributes to have them available in the access token obtained after the request: /module.php/oidc/token.php

[cicnavi]

Access Token is not the place to do that. There is one case in the spec where it says that user claims are to be returned in ID token. Take a look at https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims

The Claims requested by the profile, email, address, and phone scope values are returned from the UserInfo Endpoint, as described in Section 5.3.2, when a response_type value is used that results in an Access Token being issued. However, when no Access Token is issued (which is the case for the response_type value id_token), the resulting Claims are returned in the ID Token.

[gis-uam]

Thank you so much. We have followed your indications and we already have those attributes in the id_token. In this way we can send the data requested. Thank you very much for the help.