Device Code flow ignores `openid` scope

[svrakitin]

Describe the bug

Already discussed here #1116 (comment). Creating a separate issue as it never got traction and now it became a blocker for us to continue adoption.

Device Code flow ignores openid scope, never generates an ID token and doesn't provide it in the token response. This doesn't let headless applications (e.g. desktop applications or CLIs) to authenticate a user and personalize experience.

As a side effect, if refresh token is also present then refresh will fail with NullPointerException in

spring-authorization-server/oauth2-authorization-server/src/main/java/org/springframework/security/oauth2/server/authorization/token/JwtGenerator.java

Line 138 in f003d7e

OidcIdToken currentIdToken = context.getAuthorization().getToken(OidcIdToken.class).getToken();

To Reproduce

Go through device code flow with openid scope.

Expected behavior

Token response for Device Code flow is the same as for Authorization Code flow when given same scopes.

Ideally, any flow which involves a user should support openid scope and provide an ID token in the token response.

See references:

• https://auth0.com/docs/get-started/authentication-and-authorization-flow/call-your-api-using-the-device-authorization-flow#receive-tokens
• https://developer.okta.com/docs/guides/device-authorization-grant/main/#request-access-id-and-refresh-tokens
• https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-device-code#successful-authentication-response

[jgrandja]

@svrakitin As mentioned by @sjohnr in this comment:

... However, I think this would be a customization that needs to be made in the application as it is not in the spec. The goal of this project is to implement the specifications to the greatest extent possible. Feel free to log a separate issue with this suggestion, but I don't anticipate adding direct support for this.

To reiterate, Spring Authorization Server is a framework, that is solely focused on implementing to spec and to provide extension points that allow consuming applications to implement off-spec, if required.

OpenID Connect 1.0 supports 3 authentication flows: Authorization Code, Implicit and Hybrid (no mention of Device Code). And the OAuth 2.0 Device Authorization Grant makes no mention of openid or End-User Authentication for that matter. Based on this, the framework will not provide off-spec out-of-box support for "OpenID Connect Device Code flow".

The 3 providers you linked to have implemented off-spec. If you need to do the same you can provide your own implementation of OAuth2DeviceCodeAuthenticationProvider that looks exactly the same but with the addition of this block of code. This can easily be plugged via OAuth2AuthorizationServerConfigurer.tokenEndpoint.authenticationProvider.

I'm going to close this as the consuming application is responsible for implementing off-spec behaviour.