I have both password and authorization_code grant types enabled in my proxy. I'm also storing app end user IDs for search and revocation. This works fine with password grant using this policy:
<OAuthV2 name="token-password"> <Operation>GenerateAccessToken</Operation> <SupportedGrantTypes> <GrantType>password</GrantType> </SupportedGrantTypes> <GenerateResponse enabled="true"/> <Attributes> <Attribute name="user_id" ref="user_id" display="true"/> </Attributes> <AppEndUser>user_id</AppEndUser> <DisplayName>Generate OAuth Token: Password</DisplayName> </OAuthV2>
The user id is correctly set in the attribute and is searchable by appenduser.
When I try something similar with authorization code, the attribute sticks, but the token is not searchable. Setting the attribute in the access code works, but it's not clear if <AppEndUser> belongs in the access code generation or not. If it must be done in the token generation, how can I reference the attribute that has the same value that is correctly being set in the token? Policies below:
<OAuthV2 name="Generate-Auth-Code"> <DisplayName>Generate Auth Code</DisplayName> <Operation>GenerateAuthorizationCode</Operation> <GenerateResponse enabled="true"/> <Attributes> <Attribute name="user_id" ref="request.queryparam.user_id" display="true"/> </Attributes> <AppEndUser>request.queryparam.user_id</AppEndUser> </OAuthV2>
<OAuthV2 name="Generate-OAuth-Token-Auth-Code"> <DisplayName>Generate OAuth Token: Auth Code</DisplayName> <Operation>GenerateAccessToken</Operation> <SupportedGrantTypes> <GrantType>authorization_code</GrantType> </SupportedGrantTypes> <GenerateResponse enabled="true"/> </OAuthV2>
Solved! Go to Solution.
Hi @nathanclegg -- I don't see any documentation that says that auth code attributes get populated into the token generated from the auth code. It seems like you verified this as well. A possible way to handle this might be as follows ( you may have already gone this route 😞
Hi @nathanclegg -- I don't see any documentation that says that auth code attributes get populated into the token generated from the auth code. It seems like you verified this as well. A possible way to handle this might be as follows ( you may have already gone this route 😞
Thanks @wwitman. I was hoping for a more direct solution but I ended up implementing something very similar to this. (It's silly that this use case is not supported officially.)
User | Count |
---|---|
2 | |
1 | |
1 | |
1 | |
1 |