A definitive answer would require knowing the exact configuration and methods used to initiate the authentication in both libraries; in addition, some client application configuration settings could also be relevant. I’m also assuming that you’re using both libraries directly from within your client application and not through the hosted login page.
Having said that and based on the information provided the explanation could be one of the following:
- the Auth0.js configuration being used includes the use of an audience parameter which implies the request will be processed in OIDC compliant mode.
- the Auth0.js method being used is the
client.loginmethod which makes use of/oauth/tokenendpoint which also means an OIDC compliant response.
In an OIDC compliant response the signing algorithm used for the ID Token is forced to RS256 if the client application performing the request is considered a public client (this reference docs also explains the reasoning behind the forced use of RS256).
Since Lock is likely making use of legacy flows which don’t trigger OIDC compliance you’ll see the different behavior (the support for OIDC and API Authorization in Lock is still not completed/documented, although there’s already some support at the code level, so I’m also assuming you’re not making use of undocumented features).