How to retrieve additional claims from the ID token?

[ronnybremer]

How to retrieve additional claims from the ID token?

[ctron]

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

yew-oauth2/src/context/mod.rs

Lines 9 to 13 in 1764784

	#[cfg(feature = "openid")]
	pub type Claims = openidconnect::IdTokenClaims<
	openidconnect::EmptyAdditionalClaims,
	openidconnect::core::CoreGenderClaim,
	>;

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

yew-oauth2/src/agent/client/openid.rs

Line 178 in 1764784

.exchange_code(AuthorizationCode::new(code))

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.