Welcome to the WSO2 Identity Server source code! For info on working with the WSO2 Identity Server repository and contributing code, click the link below.
Describe the issue:
When the device grant flow is set up to use a federated IDP for authentication, the user attributes returned from the federated IDP are not returned in the token(JWT access token and id token).
How to reproduce:
Configure the device grant flow as mentioned in the document[1]
Register a federated IDP(SAML or OAuth2/OpenID), you may use a second identity server with a port offset.
Make sure the IDP claim mappings are added properly and the federated IDP returns the claims. (in case you are not sure the claims are returned properly from the federated IDP, use code grant to verify).
Configure the registered IDP to be used with the service provider that uses the device grant flow and add the requested claims on the service provider.
Configure the service provider to issue self-contained JWT access tokens or get an ID token by adding the scope=openid when making the request to the oauth2/device_authorize endpoint.
Complete the authentication flow and get the tokens. The claims are not found in the tokens.
Expected behavior:
The claims should be returned in the token even for federated users, provided that they are sent from the federated IDP and are added as requested claims in the service provider.
Analysis:
The issue occurs because the user attributes are not cached against the device code as it is done with the code grant[2][3] and retrieved when building the token[4][5]
Please test the refresh token flow as well after fixing the issue, the attributes should not be lost when using the refresh grant while the existing access token is active.
Describe the issue: When the device grant flow is set up to use a federated IDP for authentication, the user attributes returned from the federated IDP are not returned in the token(JWT access token and id token).
How to reproduce:
Expected behavior: The claims should be returned in the token even for federated users, provided that they are sent from the federated IDP and are added as requested claims in the service provider.
Analysis: The issue occurs because the user attributes are not cached against the device code as it is done with the code grant[2][3] and retrieved when building the token[4][5]
Environment information :
[1]https://is.docs.wso2.com/en/6.0.0/guides/access-delegation/try-device-flow/ [2]https://github.com/wso2-extensions/identity-inbound-auth-oauth/blob/42184c33eaf6dd6157e49fe230a85c2275e75a62/components/org.wso2.carbon.identity.oauth.endpoint/src/main/java/org/wso2/carbon/identity/oauth/endpoint/authz/OAuth2AuthzEndpoint.java#L1573 [3]https://github.com/wso2-extensions/identity-inbound-auth-oauth/blob/42184c33eaf6dd6157e49fe230a85c2275e75a62/components/org.wso2.carbon.identity.oauth.endpoint/src/main/java/org/wso2/carbon/identity/oauth/endpoint/authz/OAuth2AuthzEndpoint.java#LL1688C9-L1688C40 [4]https://github.com/wso2-extensions/identity-inbound-auth-oauth/blob/42184c33eaf6dd6157e49fe230a85c2275e75a62/components/org.wso2.carbon.identity.oauth/src/main/java/org/wso2/carbon/identity/openidconnect/DefaultOIDCClaimsCallbackHandler.java#L153 [5]https://github.com/wso2-extensions/identity-inbound-auth-oauth/blob/42184c33eaf6dd6157e49fe230a85c2275e75a62/components/org.wso2.carbon.identity.oauth/src/main/java/org/wso2/carbon/identity/openidconnect/DefaultOIDCClaimsCallbackHandler.java#L286