Upgrade from Version 1.26 to 1.36.4 introduced error with response_type=id_token token
-
We recently upgraded our AKS instance of FusionAuth (FA) from Version 1.26 to 1.36.4 to use ElasticSearch user search.
This introduced errors with "response_type=id_token token" OIDC logins.
We did not update the receiving service provider or the FA application.
But now when we run the login to the service provider we get a 502 error when POST to https://zzz.com/oauth2/authorize after logging into FA:
I have been playing around with the
- Access Token signing key
- Id Token signing key
sections under JWT section of the FA application.
But I still get an error if I leave either setting in RS256 or RS256 - 4096 length
If I update the application to HS256 - I do not get a 502 error on login to the service provider, but now the token will not decode and the service provider will not load
If I change the response_type from "id_token token" to just "id_token" I do not get a 502 error on login to the service provider, but now the token will not decode and the service provider will not load
Did something change in how FA handles response_type "id_token token" and RS256 signing keys from V 1.26 to 1.36.4?
As I said the only difference now is that we upgraded FA.
Also, like in the Docker instructions we pipe standard out to AKS logging, so I can do
kubectl logsto see the logs, but FA does not output anything meaningful:
Is there anyway to debug what is going on with the new version?
By just seeing a 502 error page after logging in and no meaningful logs in either FA AKS logs or browser developer tools means I am just trying many different things to figure out why we cannot log into this service provider anymore.
Thanks
-
So I was able to get us 75% fixed by disabling the authentication token and keeping only the I'd token enabled on the FA application side.
But I still need to fix it to get the rest of the customers into the app.
Does anyone know a better way to diagnose or see what is causing the 502 errors?
I'm surprised the dev tools or FA logs have no other details.
Thanks
-
Ok, now I think this a lambda error bug in 1.36.4
and nothing to do with id_token token
Still researching...
-
Yeah, something is definitely going on with 1.36.4, Nashorn (original engine), and JWT populate versus what 1.26 did
Very simple examples seem to work with like only a few lines of script.
But as the javascript gets longer, then things start breaking with a 502 error on FusionAuth (FA)
I wish there was better error logs but we are still getting next to nothing from STDOUT from the FA server.
I have spent hours today putting in little bits of script to see what errors
And the conditions seem random
Did 1.36.4 Nashorn get more strict, does it not like variables to be named certain things (even though I have checked against the list of reserved words ), or maybe we need to reindex the ElasticSearch against our users again?
One of the weirder bugs is, I'll have a ton of script that works and then I put in something as simple as:
jwt.dealer_number = "xxx";And then I start erroring again, if I comment or delete this new script everything starts working again.
Does anyone have these issues with the lambdas since upgrading to 1.36.4 or going from a database user search to elastic search search?
-
@fred-fred said in Upgrade from Version 1.26 to 1.36.4 introduced error with response_type=id_token token:
jwt.dealer_number
Hi Fred,
Thanks for your detailed question. To confirm, your application is using OpenId Connect for third party logins and a lambda to reconcile the id_token for the users permissions? Since changing your return type from 'id_token token' to 'id_token' you are no longer getting a 502 from the service provider but the lambda is no longer reconciling?
Just want to confirm that your application settings for JWT:
Access Token signing key -> HS256
Id Token signing key -> OpenID Connect compiant HMAC using SHA-256 (HS256)You mentioned the response type was originally set to response_type=id_token token for the oauth2/authorize endpoint. What grant type are you using?
The id_token has only been accessible since version 1.31.0 for OpenID Connect Reconcile lambda. Additionally, the id_token is signed by an asymetric key-pair, it will not be availble to the Lambda. Are you able to print the contents of the id_token inside your lambda or any other meaningful errors?
For more meaningful logs with your AKS, I suggest you look into Log Analytics workspace.
https://docs.microsoft.com/en-us/azure/azure-monitor/logs/log-analytics-workspace-overviewPlease let us know if you are able to get more meaningful logs from the above.
Are you able to log the properties that are breaking your code such as jwt.dealer_number?
Looking through the release notes, if you are trying to use Graal JS, be aware that ECMA 6 features you can't be used. Nashorn only supports ECMA 5.1.
Please see the release notes for more details and search GraalJS. Please remove any ES6 features and let us know if you are able to reconcile the lambda.
Please see the release notes for more details:
https://fusionauth.io/docs/v1/tech/release-notes
Finally, I would review the console section for lambdas to make sure you are able to access the debug method - please ensure you have enabled debugging in the admin dashboard under Customizations > Lambdas > Your lambda > Debug enabled.
https://fusionauth.io/docs/v1/tech/lambdas/#console
If the above does not resolve your issue, please open a ticket here:
https://github.com/FusionAuth/fusionauth-issues
Thank you,
Johnathon Wood
FusionAuth
-
Also, if you are using Graal, using let and const will not be supported until version 1.37.0.