How to retrieve additional claims from the ID token?

[ronnybremer]

I figured out how to get access to the claims by following the example here https://github.com/ctron/yew-oauth2/blob/17647840a9a951cee93db56a0cf0f0bb19696a79/yew-oauth2-example/src/components/identity.rs

However, is it really the only option to first serialize the claims to Json and then use Serde to serialize them back into a structure holding the claims? The additonal_claims() function only returns an EmptyAdditionalClaims struct, so I assume I am missing somewhere the option to specify my own structure during the client construction. Any help would be highly appreciated.

[ctron]

Yes, that's true. The reason for that is:

https://github.com/ctron/yew-oauth2/blob/17647840a9a951cee93db56a0cf0f0bb19696a79/src/context/mod.rs#L9-L13

Right now, we are using the following pattern to get additional information: https://github.com/trustification/trustification/blob/d39eb136262c0c1241d464faf0f1ff87f471e74d/spog/ui/crates/utils/src/analytics/mod.rs#L184-L198

The proper way to deal with this would be the allow having the Claims type a type argument as well. That would make the API a bit/a lot more complex though. Having a default type argument might be possible in the meantime. So maybe that's a solution.

I would definitely welcome a PR in this direction.

[ronnybremer]

Thank you for your response. I will read up on the documentation and see how it could solve my current issue.

Just as an initial thought it would be imperative for the crate to support additional claims. From my experience there are many IDPs out there including specific claims in their respective ID tokens and the SPA might need to react to those values.

[ronnybremer]

After reading up on the doc and also checking the source code of the openidconnect crate, it looks like the issue is unavoidable with the current implementation. The method exchange_code used here https://github.com/ctron/yew-oauth2/blob/17647840a9a951cee93db56a0cf0f0bb19696a79/src/agent/client/openid.rs#L178 already returns the ID token parsed in such a way, that all additional claims are stripped. It cannot be recovered afterwards.

For now I will try to use the user_info endpoint in order to retrieve the additional fields. However, I would like to dive deeper into the possibility of including type arguments for the ID token. I am not sure if my knowledge about Rust is good enough for that, but I will give it a try.

[ctron]

That function actually only has a type argument. One that is evaluated to the type I mentioned earlier. If that type would have a different type argument (instead of "empty") that would work just fine.