Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

best practices for access and refresh token re-use

See original GitHub issue

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"));
    public Mono<String> getToken(ConnectionContext connectionContext) {
        return accessToken;

    public void invalidate(ConnectionContext connectionContext) {
        DefaultConnectionContext newConCtx = DefaultConnectionContext.builder().from(connectionContext).build();
        RefreshTokenGrantTokenProvider newToken = RefreshTokenGrantTokenProvider.builder()
        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

Issue Analytics

  • State:closed
  • Created 6 years ago
  • Comments:7 (3 by maintainers)

github_iconTop GitHub Comments

nebhalecommented, Jun 21, 2017

@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.

cwesdorpcommented, Jun 21, 2017

@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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Token Best Practices - Auth0
Store and reuse: Reduce unnecessary roundtrips that extend your application's attack surface, and optimize plan token limits (where applicable) by storing ...
Read more >
Refresh access tokens - Okta Developer
This guide explains how to refresh access tokens with Okta. Learning outcomes. Understand how to set up refresh token rotation. Refresh access tokens....
Read more >
A Critical Analysis of Refresh Token Rotation in Single-page ...
In practice, this means that if an attacker manages to steal a refresh token from a frontend application, they can use that token...
Read more >
Antipattern: Set a long expiration time for OAuth tokens
Set the expiration time for refresh tokens in such a way that it is valid for a little longer period than the access...
Read more >
OAuth best practices - eBay Developers Program
OAuth token best practices · Access tokens are short-lived in that they expire relatively quickly after they have been minted. · Refresh tokens...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found