Does not support Password Grant Flow about oauth-server HOT 12 CLOSED

A successful token response is bound to contain the id_token as specified in the core OIDC document:
https://openid.net/specs/openid-connect-core-1_0.html#TokenResponse

from oauth-server.

Thanks for the follow up.

My understanding from the link provided is that an id_token is provided when a grant_type=authorization_code, however, in the ROPC flow, a grant_type=password is used and does not return an id_token.

https://datatracker.ietf.org/doc/html/rfc6749#section-4.3.3
https://www.oreilly.com/library/view/getting-started-with/9781449317843/ch04.html

from oauth-server.

I see where your confusion comes from. You're mixing up specifications, what you posted is about OAuth2 framework, not OIDC.

The difference in OIDC requests is in scopes, which include the openid scope for OIDC. The grant type should not matter. OIDC does not necessarily specify ROPC as an available grant but it only makes sense to have the same expectations for a successful token response as with the other grant types.

from oauth-server.

Thanks for the update

Openshift specifically calls out that it uses a ROPC flow to authenticate users via the command line:
https://access.redhat.com/documentation/en-us/openshift_container_platform/4.9/html-single/authentication_and_authorization/index

Given that OIDC does not explicitly define a ROPC flow, and while the OAuth specification does, it does not include an id_token, would it be preferable that the Openshift documentation explicitly states that it is dependent on the ROPC flow returning an id_token, and this may be dependent on the OIDC provider used?

from oauth-server.

I am not sure that such a technical detail belongs to the documentation. Normal users are not usually familiar with lower level details of their authentication stack and so it might cause more confusion than it would cause good.

While the OAuth2 servers might in general decide which token scopes they want to add to a token for a specific client, I would not expect an OIDC-capable server to drop the openid scope when requested, even with ROPC. In that case it would make more sense to respond with an error. Therefore I would rather consider an OIDC provider with such scope-dropping behavior as broken.

from oauth-server.

There appears to be a misunderstanding. The OIDC spec only specifies two grant types to use with the token endpoint, authorization_code per section https://openid.net/specs/openid-connect-core-1_0.html#TokenRequest and refresh_token per section https://openid.net/specs/openid-connect-core-1_0.html#RefreshTokens. Using these will return an id_token or refresh token along with the access token.

On the other hand, the Liberty's OIDC provider supports the OAuth 2.0 authorization flow when using the password grant type. This is documented in https://www.ibm.com/docs/en/was-liberty/nd?topic=cocpil-using-openid-connect-provider-as-oauth-20-authorization-server. Therefore, an id_token will not be returned since it will perform sections https://datatracker.ietf.org/doc/html/rfc6749#section-4.3.2 and https://datatracker.ietf.org/doc/html/rfc6749#section-4.3.3 of the OAuth 2.0 spec.

The following applies per https://datatracker.ietf.org/doc/html/rfc6749#section-3.3 since the request to the provider is considered an OAuth 2.0 request, not an OIDC one,

The authorization server MAY fully or partially ignore the scope
requested by the client, based on the authorization server policy or
the resource owner's instructions. If the issued access token scope
is different from the one requested by the client, the authorization
server MUST include the "scope" response parameter to inform the
client of the actual scope granted.

from oauth-server.

I am not sure what the problem here is, then.

If an id_token is not returned on an openid scope request, authentication from CLI will not work - by design. We will not make any further requests to check whether we're maybe actually talking to an OIDC, no id_token on openid scope request is a good enough proof we are not. Even if we obtained an access token, that only means we are likely talking to an OAuth2 server and OAuth2 has no standard method for requesting user identity.

You should still be able to log in from the browser just fine.

from oauth-server.

Thanks for the update,

The problem here as I see it is that our OIDC provider is responding in accordance with the OAuth specification for an ROPC flow, and I am unclear as to why OCP is expecting an id_token in the response since this appears to be contrary to the specification.

Is there anywhere in the standard that justifies obtaining an id_token from the ROPC flow?

Thanks

from oauth-server.

OCP is expecting an id_token in the response because it sets the openid scope in the authentication request.

Is there anywhere in the standard that justifies obtaining an id_token from the ROPC flow?

https://openid.net/specs/openid-connect-core-1_0.html#TokenResponse

This part of the standard specifies a successful token response irregardless of the flow used.

from oauth-server.

Thanks for the update, but this would only be for the grant_type=authorization_code, as per:

https://openid.net/specs/openid-connect-core-1_0.html#TokenRequest

The view being that the request from OCP is to an OAuth endpoint, not an oidc endpoint, so the openid scope is not relevant.

from oauth-server.

Thanks for the update, but this would only be for the grant_type=authorization_code, as per:

... which we can't perform in this case and so we consider only the part of the spec that is useful (and it's how it works in OpenID Connect solutions different from yours).

The view being that the request from OCP is to an OAuth endpoint, not an oidc endpoint, so the openid scope is not relevant.

Correct. And so you can see that OCP coorectly assumes it's not an OIDC provider.

/close

from oauth-server.

@stlaz: Closing this issue.

from oauth-server.