Feature: Actions for the Resource Owner Password Flow
Description: The ability to run actions on the “Resource Owner Password Flow”, in order to custom claims on access tokens
Use-case: I am setting up e2e testing as described in this blog post End-to-End Testing with Cypress and Auth0. I have some custom claims in a login action, which are not set when retrieving the the access token via the password flow for the test. If either the login actions ran as part of the password flow, or if there was another action type “password” (in addition to login and M2M) then this would be possible.
As an example, this is the cURL request I’m using to pull down the access token. (I’m using password-realm since I have a custom db set up):
curl --request POST --url https://<redacted>/oauth/token --header 'content-type: application/json' --data '{"client_id":"<redacted>","client_secret":"<redacted>","audience":"https://<redacted>/api/v2/","grant_type":"http://auth0.com/oauth/grant-type/password-realm","username":"<redacted>","password":"<redacted>","realm":"db-connection-name"}'
Hi @timtellos,
Thanks for the feature request. Make sure to click the “Vote” button!
Following up on this thread.
If we are currently unable to add custom claims to access tokens in the Resource Owner Password Flow - what options are left to developers when using a testing client such as Postman?
Prior to the deprecation of Rules - I could guarantee that this claims customization was always running.
This loss of functionality seems like a real oversight.
Looking for some insight / suggestions on how to proceed.
Sincerely.
1 Like
I have to agree with @chris.dawson.emsere. The lack of feature parity in the transition from Rules to Action, and the fact that we didn’t come across any documentation which indicated this was going to be functional gap is awkward to say the least. (I certainly glad we flagged it in testing, however would definitely have preferred to find a more elegant solution.)
I get the impression that ROPF users make up a pretty small segment of the Auth0 user base, and overlap with those who also lean-in heavily on Actions in customizing their login pipeline would be a small fraction of those.
Someone suggested there’s an argument to be made that those who are implementing a more complex solution which encompasses ROPF should also be able to encompass the extended logic which Actions provide within their own application. However having a separate implementation of business / authorization logic is by no means an ideal outcome.
While I doubt the current five votes are sufficient to see Auth0 put cycles into addressing this any time soon, I’m certainly hopeful there will eventually be some kind of reasonable equivalency.