No exposed method to get the user identity from the token

[raijinsetsu]

I've looked in the code and I do not see any way to extract the identity from the id_token without doing it myself. It seems easy enough (base64Decode(id_token.split(',')[1])), but I really think this should be a method of the Client class.

[panva]

What about having it on the returned tokenset?

[raijinsetsu]

That works too though that may incur a cost to everyone instead of just those who care to see the id-token.

…

On Fri, Dec 9, 2016, 14:37 Filip Skokan ***@***.***> wrote: What about having it on the returned tokenset? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#7 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGfltgsmhCu6ZwIy39QRWdmiuDrF4EOMks5rGa3wgaJpZM4LJQII> .

[panva]

Let me explain my thought process,

• i don't want to provide a method to just decode a token, it should be only for the one's the library has validated
• i want to avoid unnecessary double verification of tokens, as it can be, in some scenarios, quite an expensive operation
• i don't want to extend the non-function properties on a tokenset

Making it a method on the tokenset makes sure no serialization that users already have in place will pick up an extra property. Putting it on a tokenset makes it immediately available after authorizationCallback and refresh calls, which is where you possibly want to read it anyway. Other than these cases, if you lose the tokenset entity itself, there's always base64decode ;)

[raijinsetsu]

I have no concerns with this approach.

…

On Fri, Dec 9, 2016, 16:17 Filip Skokan ***@***.***> wrote: Let me explain my thought process, - i don't want to provide a method to just decode a token, it should be only for the one's the library has validated - i want to avoid unnecessary double verification of tokens, as it can be, in some scenarios, quite an expensive operation - i don't want to extend the non-function properties on a tokenset Making it a method on the tokenset makes sure no serialization that users already have in place will pick up an extra property. Putting it on a tokenset makes it immediately available after authorizationCallback and refresh calls, which is where you possibly want to read it anyway. Other than these cases, if you lose the tokenset entity itself, there's always base64decode ;) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#7 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGfltg-keAmTCWEoE9LavNPwTXW4C_wrks5rGcWAgaJpZM4LJQII> .

[panva]

See https://github.com/panva/node-openid-client/blob/master/CHANGELOG.md#version-120