Generating Access token: any upper limit on setting attributes

[Feroz_Mahammad]

Any upper limit on setting attributes while generating access tokens? If so, what is the limit? Will those attributes still exists after the token is refreshed?

[DChiesa]

let me check on that for you. How many do you WANT to attach to an oauth token?

of course if there were a limit, there are pretty easy ways to get around it. Which I can explain if necessary for you.

[gnanasekaran]

to your other question - attributes will be retained when tokens are refreshed,

while dino checks on the limit - in my experience, I have seen only couple of attributes associated with tokens, even if you need to have many [first we need to understand, why? there could be other ways to solve that], you could encode multiple values in a single variable, a simple eg, x=val1:val2:val3 etc.. can you share your usecase?

[Feroz_Mahammad]

Thank you Mukunda. My use case is Apigee is getting a set of user attributes post successful authentication of user credentials which needs to be stored for validating the key params as part of further API calls. If we store attribute values in a single variable then how do we keep track of attribute names?

[DChiesa]

You just need to have a string that can be split at two levels.

Suppose you want attr1=value1 and attr2=value2, and so on, well past 20 attributes.

You can see that you could just concatenate all of them with a character unused in any of the names or values, for example a colon as Mukundha suggested.

Then you have one unified attribute with this value:

attr1=value1:attr2=value2:attr3=value3...

at runtime, you need to split the attribute on the colon,

then work through each of the subitems and split them by the equals.

var v = context.getVariable('mycustom.attribute'),
    pairs = v.split(':');
pairs.forEach(function(pair) {
  var kv = pair.split('=');
  // kv[0] = attr1, attr2, attr3
  // kv[1] = value1, value2, value3
});

[adas]

@Mahammad Feroz The upper limit on the number of token attributes is 20. Currently you might be able to set token attributes beyond 20, but once we migrate to the new persistence layer, the limit would be enforced so I would suggest you assume 20 to be the limit.

[Feroz_Mahammad]

Thank you arghya das. couple of more queries.

1. where are those attributes stored which we set as part of generating access token?

2. Is there any role played by those attributes in generating access token?

3. Is there any limit on the size of the attributes?

[adas · Accepted solution]

@Mahammad Feroz The attributes are stored along with the token, in our datastore. So when you do "Get OAuth v2.0 Info" policy, you can fetch these attributes and write policies or custom flows based on the attributes returned. Similarly, you can use the "Set OAuth v2.0 Info" policy to update these attributes at runtime and manipulate the attributes. I am not aware of any limitation on the size of the attributes (I mean the attribute value) but I will go back and confirm with the code. But in general it would be good to stick to some finite limit on the size of the attributes, say 1024 characters.

Confirmation: The limit on the key name is 1KB and value is 20KB. The limit on the number of attributes is going to be 20.

[Feroz_Mahammad]

Thank you arghya das.