I know that /oauth/ro has been deprecated for a while, but we haven’t yet updated to use /oauth/token. It appears that without any communication (as far as i can tell?) legacy access was recently completely disabled from any newly created clients. While this may seem like a reasonable thing to do as it doesn’t actively break anyone’s existing application, it definitely can break peoples ability to promote across environments.
It’s broken our ability to migrate to a new environment (we’re following the Account per environment method as suggested in auth0 docs.).
Was there any reason this was done with no notification to users? It seems like providing a few months of notice about the date after which you can no longer create clients that can level legacy auth mechanisms would be reasonable to expect. Is it possible for this functionality can be re-enable and sunset in the future with proper notice??
If this is my fault and i missed the announced date, could you please point me to where these things are announced as it’s at least not obvious (e.g. nothing in Auth0 Support Center) so that I can follow along for future changes.
Also curious if something changed regarding the ID token?
Despite my client using HS256, the ID token I’m getting back from the /oauth/token resource owner flow is signed with RS256. This is not the case from the /oauth/ro which (for clients it still works with) is returning HS256 - is this intentional or is something misconfigured?
I mentioned this briefly in a reply to a comment you left in another question, but I’ll kind of repeat it for the benefit of other users. Also, if you have updates to the question, prefer editing it instead of posting as an answer as this may reduce the visibility of your question as it removes it from the completely unanswered questions view.
The related change as you mentioned applies only to newly created clients and it influences the default grant types allowed. We also tried to do it in a way that the default grant types allowed can, in most cases, be modified in order to still allow developers to use the non-default ones. See the available documentation on the change for additional reference information.
However, this is still a change and in some specific cases like yours, when as part of your use of Auth0 you require the creation of new accounts the disruption is increased a bit with relation to the majority of the scenarios where either a single account is used or all the accounts are already setup.
You could argue as you did that this could have been done with a notification and this was indeed considered, however, since in one way or another you can still either autonomously patch the client yourself or in the rare cases where this involves the need to create a new account with the same capability of an existing one you can contact support for an exception to be considered we opted for applying the change now as a way to have an improved default configuration sooner.
For general updates on Auth0 functionality you can consider subscribing to the changelog at: Auth0 Changelog
In relation to the ID token the behavior you’re observing, overriding the client setting, this was something that was already in place and unrelated to the client grant types changes. For an explanation of that behavior I would suggest you to check this answer to a question specific to that issue.
@jmangelo appreciate the response - i was (obviously) unaware of the changelog url and have definitely bookmarked that for the future. It looks like our ticket was handled overnight as clients in our new account now have all of the legacy permissions, allowing us to keep moving until we complete the switch to the modern oauth flows.
@jmangelo appreciate the response - i was (obviously) unaware of the changelog url and have definitely bookmarked that for the future. It looks like our ticket was handled overnight as clients in our new account now have all of the legacy permissions, allowing us to keep moving until we complete the switch to the modern oauth flows.