AppEndUser not saved in authorization code

[AlainStoffels]

As described here, we are trying to save an AppEndUser in our authorization codes. We want to save this when creating an authorization code, because we want to control it's value and not let 3rd parties do this when exchanging the auth code for an access token. When exchanging this auth code for an access token, we expect this value to carry over, just like the other properties in the auth code.

Our policy looks like this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<OAuthV2 async="false" continueOnError="false" enabled="true" name="GenerateAuthorizationCode">
    <DisplayName>GenerateAuthorizationCode</DisplayName>
    <Attributes>
        <Attribute name="company_uuid" ref="request.queryparam.company_uuid" display="true"/>
        <Attribute name="employee_uuid" ref="request.queryparam.employee_uuid" display="true"/>
        <Attribute name="shop_id" ref="request.queryparam.shop_id" display="true"/>
        <Attribute name="locale" ref="request.queryparam.locale" display="true">nl-NL</Attribute>
    </Attributes>
    <AppEndUser>request.queryparam.company_uuid</AppEndUser>
    <Operation>GenerateAuthorizationCode</Operation>
    <GenerateResponse enabled="true"/>
</OAuthV2>

However, when I get the authorization code information through this endpoint the AppEndUser is missing. Obviously, it's thereafter also missing from the access token where the auth code was exchanged for. The company_uuid attribute, which is using the same query parameter, is filled in correctly.

Because the example in the documentation was specifically for saving the AppEndUser in the access token, I was wondering if it's actually supported for the GenerateAuthorizationCode operation. The documentation doesn't explicitely confirm or deny this, and according to this answer it is supported.

I've also tried to add the AppEndUser configuration to the GenerateAccessToken operation, which does work as expected.

So my question is: Is this really supported, and if so, does anyone have an idea what's going wrong?

[dchiesa1]

I can't assure you that AppEndUser will work as you want, when Operation = GenerateAuthorizationCode.  I haven't tried this before. From your observations, it does not work as you desire. 

As you've seen , you can use AppEndUser with GenerateAccessToken.  

Maybe you can rework your flow to defer setting the AppEndUser until the time of GenerateAccessToken.  Use the stored attribute on the code, to populate the AppEndUser . Would that work? 

[AlainStoffels]

Yes, that could work as well. But I'm not sure if it's possible to read the contents of an authorization code before it's exchanged for an access token. There is the VerifyAccessToken operation which populates variables with all the custom attributes, but that only works for access tokens, not authorization codes.

I basically need to be able to read the attributes of an authorization code before the access token is created, but I can't find a way to do this. At least not with the OAuthV2 policy.

[dchiesa1 · Accepted solution]

I basically need to be able to read the attributes of an authorization code before the access token is created, but I can't find a way to do this. At least not with the OAuthV2 policy.

Yes. Not with the OAuthV2 policy. You need to do it with the GetOAuthV2Info policy. This is weird because OAuthV2 does about 17 things, but reading the attributes of a code is one thing it does not do. . . . ? I sometimes wish there were multiple distinct policies for OAuthV2, rather than a single policy with multiple different Operations. But anyway, it works the way it works, and GetOAuthV2Info is what you want.

[AlainStoffels]

Yes, that's what I was looking for. Thank you! I got so used to everything being encompassed in the OAuthV2 policy that I didn't look elsewhere. I agree that more separated policies would probably make it easier to understand and would make the documentation for such a policy easier as well.

So now I have modified my access token creation flow to first call the GetOAuthV2Info policy, which populates the variables with all the attributes, and then I refer to that variable as the AppEndUser in the GenerateAccessToken step.