Improve OAuth 2.0 Device Authorization Grant

[sjohnr]

Improvements:

• Add tests for OAuth 2.0 Device Authorization Grant #1127
• Support device code and user code in JdbcOAuth2AuthorizationService #1156
• Add sample supporting public client for OAuth 2.0 Device Authorization Grant #1157
• Add reference documentation for OAuth 2.0 Device Authorization Grant #1158

Related gh-44

[svrakitin]

Hey @sjohnr!

I noticed that PublicClientAuthenticationConverter wasn't extended for Device Authorization Grant, which makes it work only with confidential clients (with a secret), while device flow is supposed to work with public clients (without a secret).

It also doesn't provide an ID token in the token response even if openid scope is there. Is it by design?

[sjohnr]

Hi @svrakitin! I appreciate the questions.

I noticed that PublicClientAuthenticationConverter wasn't extended for Device Authorization Grant, which makes it work only with confidential clients (with a secret), while device flow is supposed to work with public clients (without a secret).

Whether the authorization server supports public clients (and how) is not really specified in the spec, only that device clients are treated the same as public clients (RFC 8628, Section 5.6). We will continue to make the same recommendation for device grant as for authorization code, and so we didn't include support for public clients. I've added the device-client sample as a minimal example of using a confidential client to proxy the flow for a SPA or native app.

It also doesn't provide an ID token in the token response even if openid scope is there. Is it by design?

The OAuth 2.0 Device Authorization Grant (RFC 8628) is not connected to OpenID Connect 1.0, does not mention the openid scope, and does not provide login functionality. Are you referring to a different specification?

[svrakitin]

Whether the authorization server supports public clients (and how) is not really specified in the spec, only that device clients are treated the same as public clients (RFC 8628, Section 5.6). We will continue to make #297 for device grant as for authorization code, and so we didn't include support for public clients. I've added the device-client sample as a minimal example of using a confidential client to proxy the flow for a SPA or native app.

Device Authorization Grant assumes a public client, as device (e.g. smart TV, POS terminal or CLI) can't really contain credentials. You linked the correct section (RFC 8628, Section 5.6). This would be similar to the browser-only clients. Recommendation to use a confidential client doesn't apply here as those shouldn't be even supported.

The OAuth 2.0 Device Authorization Grant (RFC 8628) is not connected to OpenID Connect 1.0, does not mention the openid scope, and does not provide login functionality. Are you referring to a different specification?

It is a convention across vendors (at least Okta, Auth0, Azure) to treat device flow same way as authorization code flow when openid scope is used. The only difference is that the device can't handle the callback in the browser.

• 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

[sjohnr]

Thanks for your response, @svrakitin.

Recommendation to use a confidential client doesn't apply here as those shouldn't be even supported.

According to Section 3.1 Device Authorization Request, the client authentication requirements of RFC 6749, Section 3.2.1 apply, meaning confidential clients are supported. As mentioned in the linked issue, the backend-for-frontend pattern provides a confidential client, and device clients can proxy requests through a BFF similar to browser-based apps. The BFF can allow anonymous requests, and would be responsible for protecting the backend from abuse.

On the contrary, since public clients don't have credentials, there's not a clear way to alternatively protect the Device Authorization Endpoint and it is not described in the spec. Do you have a suggestion for how to securely support public clients? I think allowing anonymous access will only be possible through customization, and the application would assume any associated risk(s).

It is a convention across vendors (at least Okta, Auth0, Azure) to treat device flow same way as authorization code flow when openid scope is used.

Thanks for providing some links. I'll review those when time allows. 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.

[svrakitin]

Thanks for linking the section @sjohnr, TIL. I wonder what would be the use-case for confidential clients going through Device Authorization flow. Authorization Code flow at least provides some basic protection via exact match on redirect URIs. Here, it is enough for credentials to be compromised.

What do we want to protect the endpoint from? Are we concerned about unauthenticated traffic? This would be the same case as Dynamic Client Registration, where you expect unauthenticated requests. Endpoint protection here is a responsibility of an application developer.

My suggestion is to enable public clients via customization option if you believe this is not secure by default. Otherwise, this doesn't cover the primary purpose of Device Authorization Grant - enable headless clients to act on behalf of users.

I am happy to contribute.

---

I also noticed that we store the client principal under authorization attribute when handling device authorization request, which seems unnecessary:

spring-authorization-server/oauth2-authorization-server/src/main/java/org/springframework/security/oauth2/server/authorization/authentication/OAuth2DeviceAuthorizationRequestAuthenticationProvider.java

Line 165 in 22fa26d

.attribute(Principal.class.getName(), clientPrincipal)

Everything works without that and avoids serializing a registered client contained in that principal.

[sjohnr]

Hi @svrakitin.

I wonder what would be the use-case for confidential clients going through Device Authorization flow.

The feedback you're providing is great. However, it would be helpful if you could read up on the links provided in gh-297 on BFF, as I'm not sure we're thinking of the same use of a confidential client in the conversation so far.

My suggestion is to enable public clients via customization option if you believe this is not secure by default.

Please log an issue for this so it can be discussed first.

I am happy to contribute.

Awesome!

Everything works without that and avoids serializing a registered client contained in that principal.

I'll keep that in mind! My initial goal was to be consistent with the authorization code implementation.

[jgrandja]

@svrakitin

I also noticed that we store the client principal under authorization attribute when handling device authorization request, which seems unnecessary

Yes, the client Principal is initially saved in the OAuth2Authorization at the start of the flow, however, when the user-interaction steps are initiated, the End-User Principal is updated in OAuth2Authorization replacing the client Principal.

My suggestion is to enable public clients via customization option if you believe this is not secure by default. Otherwise, this doesn't cover the primary purpose of Device Authorization Grant - enable headless clients to act on behalf of users.

@sjohnr and I are currently discussing various options on providing support for Public Clients. It will likely be via customizations by the consuming application. We'll be sure to include you when we have more information so we can hear your feedback.

[svrakitin]

@jgrandja

Yes, the client Principal is initially saved in the OAuth2Authorization at the start of the flow, however, when the user-interaction steps are initiated, the End-User Principal is updated in OAuth2Authorization replacing the client Principal.

I just had to allowlist OAuth2ClientAuthenticationToken class when serializing attributes before persisting them to the database. It is currently missing from https://github.com/spring-projects/spring-authorization-server/blob/main/oauth2-authorization-server/src/main/java/org/springframework/security/oauth2/server/authorization/jackson2/OAuth2AuthorizationServerJackson2Module.java#L74, which I use as reference for my own implementation.

[jgrandja]

@svrakitin

I just had to allowlist OAuth2ClientAuthenticationToken class when serializing attributes

I see the issue now. This has been fixed in 5b690df

[jgrandja]

@svrakitin

My suggestion is to enable public clients via customization option if you believe this is not secure by default. Otherwise, this doesn't cover the primary purpose of Device Authorization Grant - enable headless clients to act on behalf of users.

It's possible to allow public clients for device grant via customization of OAuth2AuthorizationServerConfigurer.clientAuthentication(). See this branch/commit for full working sample. We will likely merge this with our current sample and document it in the reference manual as well.

[svrakitin]

@jgrandja

Thanks. That's how I've implemented it as well, it's just something I'd like to have out of the box. :)

Why client-specific consent settings are no longer taken into account when deciding whether to ask for consent? This line was dropped 1354ca4#diff-286505367c851db9d5dd851f4a0773459e01d93338778b453a7c067ed193e940L185

[jgrandja]

@svrakitin

Why client-specific consent settings are no longer taken into account when deciding whether to ask for consent?

As per section 5.4 Remote Phishing:

it is RECOMMENDED to
inform the user that they are authorizing a device during the user-
interaction step (see Section 3.3) and to confirm that the device is
in their possession. The authorization server SHOULD display
information about the device so that the user could notice if a
software client was attempting to impersonate a hardware device.

The default for ClientSettings.isRequireAuthorizationConsent() is false, so it would bypass the consent screen in the default configuration, hence the removal of that check.

Is this a concern for you? If so, do you have a suggested improvement?

[svrakitin]

@jgrandja Thanks. It is fine, I was just curious, because it wasn't consistent with Authorization Code flow.