The audience of a JWT access token is included by making use of the
aud claim which is defined as part of RFC 7519:
In the general case, the “aud” value is an array of case-sensitive strings, each containing a StringOrURI value. In the special case when the JWT has one audience, the “aud” value MAY be a single case-sensitive string containing a StringOrURI value.
Even though the specification allows for a single audience to be expressed directly as a string this is optional and the use of an array to represent it would also be valid. The reason I mention this is that the change you describe should not have any functional impact as any processing of a JWT audience should be equivalent no matter if the single audience is represented as a string or within a one element array.
In conclusion, the issue with
/userinfo should not be related to the change in the representation. Check the following related question and associated answer to see if it’s relevant for your situation: