Why does OpenIdUserDetailsMapper no longer support making a call to an external api during createAuthenticationResponse?

[rdamus]

just spent the weekend upgrading micronaut from 1.3.4 to 2.4.0. as we used the security package for OAuth/OpenId workflow with Intuit's Quickbooks Online (QBO), i spent a reasonable amount of time with both the OpenIdUserDetailsMapper and the OauthUserDetailsMapper. in previous version of micronaut security i was able to implement the OpenIdUserDetailsMapper for a named singleton bean that could make a call to the QBO user profile endpoint to populate the UserDetails object it was returning. however, this no longer seems to be the case with the OpenId connect workflow; any call that i make with a declarative client in the new createAuthenticationResponse method (even tried annotating the method with @ExecuteOn) does not complete. why was this change made? or is there some other way to call into another api without breaking the control flow, much like you support in the OauthUserDetailsMapper?

example code that works in OauthUserDetailsMapper but fails in OpenIdUserDetailsMapper. note this exact call used to work in micronaut 1.3.4 with mn-security < 2.0

 @Override
    public Publisher<AuthenticationResponse> createAuthenticationResponse(TokenResponse tokenResponse, @Nullable State state) {
        log.debug("---createUserDetails:QuickbooksOAuthUserMapper---");
    //the format for the Authorization header is "Bearer <access-token>"
        return client.getUser("Bearer " + tokenResponse.getAccessToken())
                .map(user -> {
                    List<String> roles = Collections.singletonList("ROLE_ADMIN");
                    Map<String,Object> attribs = new HashMap<>();
                    attribs.put("email", user.getEmail());
                    return new UserDetails(user.getLogin(), roles, attribs);
                });
    }

[sdelamo]

I understand you are migrating from Micronaut 1.x to Micronaut 2.x and thus upgrading Micronaut Security as well.

Have you checked the What's new version and Breaking changes section of Micronaut Security 2.0

[rdamus]

Yes, indeed reviewed all the documentation; it was a big help in doing the upgrade. I'm more asking about what would prevent the OpenId control flow from completing when i add a call to an external api?

Here's the issue: QBO behaves slightly differently than how you designed the OAuth and OpenId flow, so i am sort of inbetween using one or the other, and i end up defaulting to the OpenID connect flow. For reference, see here

Specifically, 1) QBO generates claims that are not observable in the OAuth flow, which means 2) i have to use the openID flow to get the claims, which leads to another issue (see below).

(1) occurs because of how the TokenResponse object is designed - this object does not map additional claims sent at the initial exchange. For example, the realmId claim is sent back in the initial OAuth response, but TokenResponse is not built to access this claim.

(2) means that I use the openID flow to successfully retrieve the realmid claim, but i end up being unable to retrieve additional user-specific information that i would want for my UserDetails object. In essence, even though i'm using the openID flow, i still need to make another call to the "user profile endpoint" - /userinfo - before the openID flow completes - to fully populate my UserDetails object. In other words, even though you pass the OpenIdClaims object to the createUserDetails method, this object (which is essentially a map) does not contain all the data for the user as QBO is simply not providing the information in the returned payload, so it does not appear in the OpenIdClaims map.

i feel like this is the correct part of the flow to make an explicit call to the userinfo endpoint that QBO supplies (and that currently Micronaut does not do anything with - see here).

And i was able to make such a call in the previous version of micronaut security, hence my question.

For example, i cannot gain access to the email info that i specified earlier in the clients.*.scopes without making a call to the QBO userinfo endpoint.

This is what my oauth2 scopes look like to enable the :

oauth2:
         callback-uri: ${micronaut.server.context-path}oauth/callback{/provider}
         login-uri: ${micronaut.server.context-path}oauth/login{/provider}
         clients:
            quickbooks:
               scopes:
               - com.intuit.quickbooks.accounting
               - openid
               - email
               - profile

[sdelamo]

Could you replace the class DefaultOpenIdAuthorizationResponseHandler. It seems you want to do an additional network call in createAuthenticationReponse which should be possible.

[rdamus]

Ok I will try this out and get back to you

[maccuaa]

The problem with this approach is the OpenIdAuthenticationMapper.createAuthenticationResponse method does not return a Publisher which means any API call made to fetch additional user info would need to be blocking. This is in contrast to OauthAuthenticationMapper class where the createAuthenticationResponse method does return a Publisher. This was raised in #927