best practices for access and refresh token re-use

What is considered the best usage of creating a CF client when we have an access and refresh token stored (like the CLI client does)?

Current we use the PasswordGrantTokenProvider to extract the access and refresh token from the login response and store that locally. When we need to connect to CF again (with a new instance of the client) we implemented a class from the TokenProvider interface that has the accessToken, and when this is invalid we renew it in the invalidate() method using a RefreshTokenGrantProvider.

So the question is, what is the best approach to create a TokenProvider with a known access and refresh token?

Our current implementation looks like this

final Properties props = new Properties();
TokenProvider tp = new TokenProvider() {
    
    Mono<String> accessToken = Mono.just(props.getProperty("accessToken"));
    
    @Override
    public Mono<String> getToken(ConnectionContext connectionContext) {
        return accessToken;
    }

    @Override
    public void invalidate(ConnectionContext connectionContext) {
        DefaultConnectionContext newConCtx = DefaultConnectionContext.builder().from(connectionContext).build();
        RefreshTokenGrantTokenProvider newToken = RefreshTokenGrantTokenProvider.builder()
            .token(props.getProperty("refreshToken"))
            .build();
        
        try {
            accessToken = newToken.getToken(newConCtx)
                    .doOnSuccess(s -> System.out.println("Got a new token: " + s));
        } catch (Exception e) {
            throw new IllegalStateException("Something is wrong renewing our token", e);
            
        }
        System.out.println("We'll get you a new token!");
    }
};

Please advice

[nebhale]

@cwesdorp It’s important to remember that there are only two types that maintain any significant state, the ConnectionContext and the TokenProvider. In your multi-tenant situation I’d recommend having

• A single ConnectionContext used by all requests (if there is a single target host, multiple if there are multiple target hosts)
• Multiple cached (LRU?) TokenProviders keyed by the user
• Disposable *Clients created on each incoming request

By far the most expensive (resource-wise) component is the ConnectionContext. It contains the thread and connection pools and is designed to be used for any and all requests, even with different users. The TokenProviders store valid tokens, resulting in fewer network calls for them and renegotiate when a 401 is received. Since there is some unnecessary overhead in negotiating a token when you’ve got a valid one it makes sense to cache these. Beyond that, a CloudFoundryClient (and its peers) is totally stateless, simply combining a ConnectionContext and a TokenProvider to make a REST call. You can create and destroy these quickly, easily, and regularly with no real penalty.

The client is designed so that you can mux ConnectionContexts and TokenProviders in any combination and they’ll behave properly. This allows you to cache expensive resources in memory and mix and match them in lightweight clients as needed.

[cwesdorp]

@nebhale Thanks for the guide lines. I’ll understand the idea and have a sample application from which I came to that conclusion, good that you confirm this.