When i’m logging in on my client I receive a hs256 token but my ASP.NET Web Api backend only supports RS256.
I did choose RS256 when you go to your client and then advanced settings → oauth. Can someone please explains me why I receive a hs256 token instead of rs256.
If it matters my front-end is written in Angular.
Update:
I re-saved my settings of saving my token as a RS256.
Client:
Api:
If I do a post call like this I do get a correct RS256 token:
I used this https://github.com/auth0-samples/auth0-angularjs2-systemjs-sample/tree/master/01-Login sample and I changed the client settings to my client setting. So I can succesfully login, but if I then log my token I get an HS256 token instead of an RS256. What is going wrong?
I’m not aware of any situation where choosing RS256
as the signing algorithm for the client application would not be respected when issuing the ID token so although a long-shot can you double-check that you saved your changes when you switched the algorithm type. I sometimes fail to do this when doing some tests around client applications and it would be the simplest explanation to the behavior you’re experiencing.
Also have in mind that this setting is meant to affect the signing algorithm of the ID Token. If you’re also using API Authorization related features (which may be the case as you mention the use of an ASP.NET Web API) then the signing algorithm of the access token issued to the API in question is chosen at the API settings level and is not affected by the client application setting you mentioned.
Update:
Thanks for double-checking and providing more information. I checked your configuration and the client you mentioned DFhBr4aH8uAIelzdD5...
is indeed correctly configured, however, I noticed that you have more than one client application configured, more specifically, you have an additional client application named angular-test
that is still configured to use HS256
. Are you using more than one client in your tests?
@jmangelo ,I checked this and you were right. I’m literally feeling stupid right now.
Now I do get a RS256 token back, but it still doesn’t give me authorization. Any idea why this happens?
An example of the token from the client:
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ik9EZzNRVVpDTkRKRFFrUTVOall3TmpjMFFVTTBRell4UVRVMk9VRkZSamRGTkRoR01UYzFSUSJ9.eyJpc3MiOiJodHRwczovL2ludGVybmNvLmV1LmF1dGgwLmNvbS8iLCJzdWIiOiJERmhCcjRhSDh1QUllbHpkRDVSMUx2RlgzUE9nYXVOSkBjbGllbnRzIiwiYXVkIjoiaHR0cDovL2FwaS5pbnRlcm5jby5ldSIsImV4cCI6MTQ5MzgyNDA4OCwiaWF0IjoxNDkzNzM3Njg4LCJzY29wZSI6IiJ9.UVZnjIK6OAxtf5Nw4yNrtf3HAijzQQS1sfhC0dQ1EYK8fko-nTbBVqQ4bgJOJz6ZQ-rOKIAWsOx8QjCPLkbdYHIL6xCnsuinsAKCwBQKADdSxGyTVZERWYKzaMeqNR4_LPMn8HhZ0S27LQPzPQdAY3j6-yIkw9y7hW4lSmwZKXheIB9yON5E7lNd8HABBtyXjvpEB8mX2EoQ0J9TNsNp26otVGldSuH3acRmty0znrS3FTajV5bEiEen4JF1Tjc2Y-HnDKAQTWolpp5xBOdNlvgE0UK_PWPLz8G8xJFvIEm-oTfafWnD_-FP-PCGsFfqyW7YH-AErpBftrA5FcRZFg
Which results in:
![jwt decoded][1]