Multiple authentication handler abstraction

[rafaelrenanpacheco]

Hello there!

Where I work at our UAA must handle different ways of authentication. For example, with the grant Resource Owner Password Credentials our UAA offers 3 ways of authentication:

• Default:
  • e-mail
  • password
• Credentials:
  • user's social number, company registration number, etc
  • password
• Delegation:
  • target a custom microservice to authenticate the user

For the grant Client Credentials it offer 2 ways:

• Default backend client credentials
  • Authentication used between our microservices to call each other.
• External client credentials
  • Third party application that communicate with our endpoints.

Using the legacy authorization server it was not nice to achieve this behavior. For example, the default email+password was a first class citizen, while other handlers had to "try hard" to be put to work.

Since the announcement of the authorization server discontinuation I wrote a new UAA for our company, and since I knew that there would be N ways of handling a specific grant type, I designed the application in order to facilitate the handler implementations.

But, now that Spring will create a new authorization server, I will try to use it instead of our own, even tho our own works perfectly fine. I just don't like reinventing the wheel.

Finally, my request is (and I guess this would already be on yours todo list) to abstract the authentication handlers so it would be easy to enhance the authorization server with N ways of authenticating a user (following the OAuth2 framework, of course). There should not be a first class citizen (looking at you UserDetailsService), but instead it should offer a nice abstraction for us to add the required ways of authentication.

This is just to clarify the idea, and by all means not how you should do it, but this is what we did in our UAA: The handlers must have some kind of way to answer the question: "should I handle this authentication request?". In order to answer that our handler interface has 2 methods:

• Boolean canHandleGrantType(GrantType grantType)
• Boolean canHandleAuthentication(TokenRequest tokenRequest, HttpServletRequest request)

The first one is the cheaper one. It will answer if it can (so far) handle the authentication grant type. For example, the DelegationAuthenticationHandler can handle GrantType.PASSWORD. So if the request is to authenticate client credentials, this handler would be skipped.

The second one will answer if it will handle that authentication based on those two parameters. For example, the DefaultAuthenticationHandler will handle it if the tokenRequest (which has the username) contains an username with @ and the http request doesn't have a delegation header.

And what about if 2 handlers can handle the same request? We defined that if the handler returns null it means "I didn't find the user, but other handler can try it". This will not stop the authentication process to try another available handler. If the handler throws a specific exception, this means that the authentication has failed and no more handlers should be tried.

From the example above we have 2 handlers. Which one should handle first? We control that with a simple @Order on our handlers.

Again, all this above is just to clarify the idea and the need for multiple handlers for every grant type.

Best regards.

[tomvandenberge]

Please keep in mind that the use of the Resource Owner Password Credentials grant is strongly discouraged according the OAuth 2.0 Security Best Current Practice. Enhancing the authentication as you describe for this grant type might therefore not be appropriate, as it might encourage people to use it. In my opinion, it should even be considered to not implement this grant type, or maybe in a separate module for backward compatibility.

Regarding the Client Credentials grant, I don't fully understand why the default authentication doesn't work for you. For both use cases you mention, don't you have a client ID and client secret?

[rafaelrenanpacheco]

@tomvandenberge, thanks for the feedback!

I did some research and what you said about "it should even be considered to not implement this grant type" makes complete sense regarding this new Spring Authorization Server and the OAuth2 best current practice.

In our scenario we are (still) handling the authentication, even tho the best practice points toward using authorization code flow (for authorization) and OpenID (for authentication), just like what Google offers today. So, if the recommendation is to delegate authentication and authorization to an OpenID server, like what Google has, I don't understand the necessity of this new Spring Authorization Server. If the objective of Spring Authorization Server is to provide the flows described as best practice, this would mean that one would use this project to create a custom authorization code flow, with it's own user database. This would result in typing username and password in that application, which is the bad practice that ROPC has.

I withdraw my feature request, but I would like to understand further how this new project would adhere to the OAuth2 best practices, which tries to "please don't ask the user for it's username and password on your domain".

[jgrandja]

@rafaelrenanpacheco Thanks for your detailed report. From what I gather, your main requirements are password and client_credentials grant. And you require an easy way of plugging in your specific user database that ultimately validates the user's credentials in the password grant flow.

FYI, as @tomvandenberge mentioned, password grant is not recommended and in fact is deprecated in OAuth 2.1. We likely will not implement the password grant. However, we will ensure that custom grants can easily be implemented and configured. Please keep track and provide feedback as we build it out to ensure we are achieving this goal.

The client_credentials grant is the first one we are implementing so please track #19 to ensure the development provides the customizations you are looking for.

I'm going to close this issue since it's more of a "statement of requirements" that you are looking for. If you require a specific feature please log a new ticket detailing the specific feature you require. It's always best to keep new feature requests as small as possible. If you mention a few things in the issue then it likely has to be broken up into multiple issues.

[tomvandenberge]

@rafaelrenanpacheco the difference between the password grant and the authorization code grant is that with the password grant, the client application submits the user's password (entered in the client application) to the authorization server. The client has access to the password. With the authorization code grant, the client redirects the user to the authorization url of the authorization server, where he authenticates. In this scenario, the client application never gets to see the user's password, which is far more secure.

[rafaelrenanpacheco]

I'm aware of how these grant works, my question was related on what this new spring authorization server will offer. If it will offer authorization code grant, it means someone will use this project to be the authorization server, in which case this authorization server will expect an username and password input. Creating applications that request username and password seems to me what these specs are trying to avoid.

Being more direct, I think they are saying: Use google's auth server (or facebook) with authorization code flow and PKCE. Do not ask the user for it's password on your domain, please and thank you.

[tomvandenberge]

In the scenario where you are managing your user's identities yourself (if you can not or don't want to use e.g. Google as an identity provider), you must use your own authorization server. Your users will have to enter their credentials on your authorization server, which is not a problem. What you don't want is that the client application asks for the user's credentials (to forward them to the authorization server using the password grant), because the client application is not in your (the authorization server's) security domain. In a web environment, there is no need for any client application to know the user's credentials. Doing so will increase the attack surface, which is the reason why this grant type should not be used.

[rafaelrenanpacheco]

@tomvandenberge thanks for the explanation, now it's much more clear. Indeed, asking the user for it's credentials and then forwarding it to a 3rd party authorization server with ROPC seems really dangerous, the first auth server (middle man) can change the claims at will without the user's knowledge.

One thing that my original post didn't make it clear is that we are not using the password grant to forward it to a 3rd party authorization server. We are using it as a mean of authentication, not authorization. When the password grant request reaches our authorization server, we handle it on that very authorization server, by querying the user database, checking the hashed password and so on.

[dfcoffin]

Are we confusing Authorization and Authentication? The OAuth 2.0 standard does NOT provide Authentication, in fact it clearly states it is outside of the scope of the standard. The standard requires a user to be Authenticated, but not by the Authorization Server.

[rafaelrenanpacheco]

Are we confusing Authorization and Authentication?

At first, yes, usually because the old spring authorization server have some features targeting authentication alongside with authorization, like this and this. After the discussion in this issue it became clear to me that OAuth2 is about authorization, not authentication.