OAuth2 server with AccountPasswordMustChangeException

[Ken Hopkins]

I am using CAS as an OAuth2 server with REST Authentication.  My client is a javascript application using the oauth2 password grant type.

When trying to authenticate a user whose password is expired, my REST authentication endpoint is returning a 428 response as expected.  I see a log message that indicates as much:

INFO [org.apereo.cas.authentication.PolicyBasedAuthenticationManager] - <[RestAuthenticationHandler] exception details: [Account password must change for a...@def.com].>

However, my client application just receives a generic 401 response from CAS indicating the authentication failed, without any indication that the password was expired.

Is this the expected behavior?  Am I missing any configuration that would allow CAS to return a different response or header or response code to an OAuth2 Password Grant Type request?  I'd like to be able to relay to the client that authentication failed because the password is expired.

I've tried returning both the X-CAS-Warning and X-CAS-PasswordExpirationDate response headers from my REST Authentication endpoint, but they do not get propagated to the response to my Oauth client from CAS.

I also enabled the password management module, but that didn't seem to help either.

cas.authn.pm.core.enabled=true

cas.authn.pm.webflow.enabled=true

cas.authn.pm.enabled=true

I'm currently using CAS version 6.2.5.

Thanks,

Ken

[Ray Bon]

Ken,

The authentication provider should _not_ return reasons for failed login to clients. Log in and any items associated with it, such as password management, should be managed entirely by the auth provider. This is to prevent abuse by client applications as well as separation of concerns (who wants to add password management to every client app?).

I have not used the password management module. It can handle expired passwords, https://apereo.github.io/cas/6.3.x/password_management/Password-Management.html.

Have you included the dependency?

Ray

On Tue, 2021-05-25 at 12:42 -0700, Ken Hopkins wrote:

Notice: This message was sent from outside the University of Victoria email system. Please be cautious with links and sensitive information.

[Ken Hopkins]

Thanks for the quick response Ray.

I did try including and enabling the password-management module, but didn't try much configuration beyond that.

In our case, the UI is a javascript application that just interacts with CAS through an API.  We wouldn't plan to enable the oauth2 password grant type for clients that weren't trusted.  Accordingly, we were hoping to trust the client to manage resetting the password if it's expired.

At first glance, the password-management module seems to be focused on CAS providing a password reset UI, which isn't our preferred experience.

I did see this bit in the link you provided:

> The password management features of CAS are rather modest, and alternatively should the functionality provide inadequate for your policy, you may always redirect CAS to use a > separate and standalone application that is fully in charge of managing the account password and associated flows.

That sounds interesting, but really, instead of redirecting to another application, we're just looking for CAS to indicate that the password is expired in the response.