Oauth tokens not searchable for auth code grants

[#1]

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>

[willwitman · Accepted 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 😞

• In the policy that generates the auth code, set GenerateResponse to false.
• Immediately after the auth code is generated, you can store the code/userid in KVM using the KVM policy.
• When you later generate the token, just before the OAuthV1/GenerateToken policy executes, pull the userid out of KVM and store it in a flow variable. Then, in the GenerateToken policy, use that variable to populate the AppUserId attribute in the token.

[#3]

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.)