I have a problem with the token signature algorithm. I selected HS256 and it works for fb login but when I try to log in with “Username-Password-Authentication” server returns RS256 token. OIDC compliant is disabled. I use iOS sdk. I also decoded token and it shows that contains audience field. It strange because I don’t use audience in my request.
Does somebody know what is wrong?
Hi, I just wanted to hop on this ticket here, cause I was about to create the same ticket. I also have disabled OIDC and HS256 enabled on my client. I’m logging in via the hosted login page from a react single page application. But I always get a access token with RS256, which can not be handled by my server/framework.
I have this with OIDC enabled, an RS256 jwt is returned when a HS256 ought to be.
For me it seems that the API which I’m authenticating for requires RS256 encryption. In the end I ended up to manually verify the token on my server, cause no library seem to support it as of now.
I recently upgraded from Lock to the Auth0 Swift library and am encountering this exact issue. My server and mobile clients have been using HS256 for ages, and suddenly I can only get RS256 tokens from Auth0. It seems forced.
Based on the fact that you mentioned that it works for social connection and not database connection then the most likely cause is that the SDK call you’re performing is going through /oauth/token for the username/password scenario. That endpoint implies OIDC compliance behavior even you did not explicitly enabled it.
See this other answer for additional information on this situation. For a mobile application, the recommendation is to adapt it to support the validation of RS256 ID tokens. Have in mind that ID tokens are only meant to be consumed by the client application itself and that they are always a JWT where the aud claim is the client application identifier. If you need a token to then send to your back-end API as an authorization method then you should be relying on access tokens (see API Authorization). In this case, since the back-end API can keep a secret you can freely choose to use HS256 signed JWT access tokens.