[ 
https://issues.apache.org/jira/browse/HADOOP-18510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624952#comment-17624952
 ] 

ASF GitHub Bot commented on HADOOP-18510:
-----------------------------------------

qcastel commented on code in PR #5082:
URL: https://github.com/apache/hadoop/pull/5082#discussion_r1006566902


##########
hadoop-tools/hadoop-azure/src/main/java/org/apache/hadoop/fs/azurebfs/oauth2/AzureADAuthenticator.java:
##########
@@ -168,12 +168,14 @@ public static AzureADToken getTokenFromMsi(final String 
authEndpoint,
    */
   public static AzureADToken getTokenUsingRefreshToken(
       final String authEndpoint, final String clientId,
-      final String refreshToken) throws IOException {
+      final String clientSecret, final String refreshToken) throws IOException 
{
     QueryParams qp = new QueryParams();
     qp.add("grant_type", "refresh_token");
     qp.add("refresh_token", refreshToken);
-    if (clientId != null) {

Review Comment:
   Nope, the client id is not optional in the refresh token grant flow. Thats a 
miss interpretation on your part of the spec.
   
   I think you have been miss leading by how it's written in the spec in 
section 6
   https://www.rfc-editor.org/rfc/rfc6749#section-6
   
   here it doesn't say in that section that the client id is required, just 
because there is different way to inject the client credential into the request 
(ie POST or BASIC, even client assertion).
   But you see in the example that the authorisation header is setup and this 
contains the client ID in there.
   
   For confidential client, its quite obvious that the client ID is required. 
For public client (which you want to support too), it's also required, as said 
in:
   
   ```
   authenticate the client if client authentication is included and
         ensure that the refresh token was issued to the authenticated
         client, and
   ```
   
   Your code currrently only support one type of auth method, the POST one.
   You then can assume that in this line, the client ID is required.
   
   You can revisit injecting it in the body of the request if one day you 
decide to support the auth method BASIC as well. Would just mean the client ID 
is in the request but in a header instead.





> Azure RefreshTokenBasedTokenProvider is only supporting public client
> ---------------------------------------------------------------------
>
>                 Key: HADOOP-18510
>                 URL: https://issues.apache.org/jira/browse/HADOOP-18510
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: fs/azure
>    Affects Versions: 3.3.4
>            Reporter: Quentin Castel
>            Priority: Major
>              Labels: pull-request-available, security
>
> The Azure RefreshTokenBasedTokenProvider is assuming the client is public, 
> meaning it's not exchanging the refresh token to an access token with the 
> client secret.
>  
> This limitation is not really justify and the RefreshTokenBasedTokenProvider 
> should use the client secret if present.
>  
> From my understanding, there is no particular reason to think that hadoop is 
> not able to store secrets securely, especially as I see the client credential 
> flow, which require a confidential client, is supported by the library.
>  
> The fix is to simply inject the client secret in the request, using client 
> basic auth method or client Post auth method, when the client secret is 
> present.
>  
> https://github.com/apache/hadoop/blob/trunk/hadoop-tools/hadoop-azure/src/main/java/org/apache/hadoop/fs/azurebfs/oauth2/RefreshTokenBasedTokenProvider.java#L61



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to