Menu
▾
▴
unity-idm-discuss
|
From: Sander A. <sa....@fz...> - 2025-10-06 11:59:00
Attachments:
smime.p7s
upstreamARCs.log
|
Hi Krzysztof, hi Roman, we encountered an issues where a public OAuth client gets error, when it tries to get a new access and refresh token, using a refresh token. The output translation profile creates an error because it can not access upstreamACRs. Which might make sense, since in using refresh tokens you do not have an upstream ACR. Would it make more sense to store the information from the original login and send the result instead of trying to resolve it again? I assume the same issue comes up for confidential clients. I also attached the stack trace itself. Best regards, Sander -- Large-Scale Data Science Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Dr. Stephanie Bauer (stellvertretende Vorsitzende), Prof. Dr. Ir. Pieter Jansens, Prof. Dr. Laurens Kuipers ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Krzysztof B. <kb...@un...> - 2025-10-10 12:14:50
|
Hi Sander, W dniu 6.10.2025 o 13:58, Sander Apweiler pisze: > Hi Krzysztof, > hi Roman, > > we encountered an issues where a public OAuth client gets error, when > it tries to get a new access and refresh token, using a refresh token. > The output translation profile creates an error because it can not > access upstreamACRs. Which might make sense, since in using refresh > tokens you do not have an upstream ACR. Would it make more sense to > store the information from the original login and send the result > instead of trying to resolve it again? > > I assume the same issue comes up for confidential clients. > You are right: upstreamACR and several other variables in the output profile are not accessible during token refresh. I'd like to understand your question better. Do you suggest the output profile provides information from the original authN (which happened during initial access token creation)? Or rather to expose information from the refreshed token? Or just that this is token refresh? Thank you, Krzysztof |
|
From: Sander A. <sa....@fz...> - 2025-10-14 07:08:34
Attachments:
smime.p7s
|
Good morning Krzysztof, at the moment we have the problem, that usage of refresh tokens fails due to missing ACR information. Our idea was to send the information from the original authN. If you feel more comftable with removing them from the token, it is also fine. If the RP would need ACR information, it would need to do a step-up authentication after using a RF token. Best regards, Sander On Fri, 2025-10-10 at 14:14 +0200, Krzysztof Benedyczak wrote: > > Hi Sander, > > > > > W dniu 6.10.2025 o 13:58, Sander Apweiler pisze: > > > > > > Hi Krzysztof, > > hi Roman, > > > > we encountered an issues where a public OAuth client gets error, > > when > > it tries to get a new access and refresh token, using a refresh > > token. > > The output translation profile creates an error because it can not > > access upstreamACRs. Which might make sense, since in using refresh > > tokens you do not have an upstream ACR. Would it make more sense to > > store the information from the original login and send the result > > instead of trying to resolve it again? > > > > I assume the same issue comes up for confidential clients. > > > > > > You are right: upstreamACR and several other variables in the output > profile are not accessible during token refresh. > > I'd like to understand your question better. Do you suggest the > output profile provides information from the original authN (which > happened during initial access token creation)? > > Or rather to expose information from the refreshed token? Or just > that this is token refresh? > > Thank you, > Krzysztof > > _______________________________________________ > Unity-idm-discuss mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss -- Large-Scale Data Science Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Dr. Stephanie Bauer (stellvertretende Vorsitzende), Prof. Dr. Ir. Pieter Jansens, Prof. Dr. Laurens Kuipers ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Krzysztof B. <kb...@un...> - 2025-10-28 16:29:38
|
Hi Sander, After research of this topic: you are right, Unity is misbehaving. In general during access token refresh, authn_time and acr claims should be preserved. I've opened ticket to fix that. Thank you for pointing that up, Krzysztof W dniu 14.10.2025 o 09:08, Sander Apweiler pisze: > Good morning Krzysztof, > at the moment we have the problem, that usage of refresh tokens fails > due to missing ACR information. Our idea was to send the information > from the original authN. If you feel more comftable with removing them > from the token, it is also fine. If the RP would need ACR information, > it would need to do a step-up authentication after using a RF token. > > Best regards, > Sander > > > On Fri, 2025-10-10 at 14:14 +0200, Krzysztof Benedyczak wrote: >> >> Hi Sander, >> >> >> >> >> W dniu 6.10.2025 o 13:58, Sander Apweiler pisze: >> >> >>> >>> Hi Krzysztof, >>> hi Roman, >>> >>> we encountered an issues where a public OAuth client gets error, >>> when >>> it tries to get a new access and refresh token, using a refresh >>> token. >>> The output translation profile creates an error because it can not >>> access upstreamACRs. Which might make sense, since in using refresh >>> tokens you do not have an upstream ACR. Would it make more sense to >>> store the information from the original login and send the result >>> instead of trying to resolve it again? >>> >>> I assume the same issue comes up for confidential clients. >>> >>> >> >> You are right: upstreamACR and several other variables in the output >> profile are not accessible during token refresh. >> >> I'd like to understand your question better. Do you suggest the >> output profile provides information from the original authN (which >> happened during initial access token creation)? >> >> Or rather to expose information from the refreshed token? Or just >> that this is token refresh? >> >> Thank you, >> Krzysztof >> >> _______________________________________________ >> Unity-idm-discuss mailing list >> Uni...@li... >> https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss |
Thanks for helping keep SourceForge clean.
X