Support for refresh_tokens?

[rbren]

We recently learned that all access_tokens are now expiring after 1 year. Are there plans to support refresh_tokens in this library?

[theckman]

I'm not entirely familiar with what you're referring to. Could you share a link?

[rbren]

HYG: https://docs.google.com/document/d/1GjyNU_rKAeX5ugFKDu8PsVY8IyDx-CxiTOJRoNRaEFU/edit

[theckman]

@rbren this is the first I'm hearing of this change, so I appreciate you forwarding that over. Reading that document makes me realize that it seems disorganized on the PagerDuty side, where in that document they talk about adding refresh_token support but it's not mentioned anywhere in their API docs. 🤦‍♂️

Anywho, to your question...

As of today this package is not involved with the OAuth token negotiation process, and instead expects consumers to do that and pass the token to the client. So I think the initial answer to your question is that there are no plans for that right now, and consumers would need to do that going forward.

I think it would be a pretty substantial change to the client to support that, and so I think we'd need to be thoughtful/intentional about it if we do plan to support it.

Edit: What I mean by this last paragraph, is it then opens questions about how to manage the lifecycle of things like the refresh_token. So if we do negotiate a new bearer token in the background, and are provided a new refresh_token as well, how do we make sure to hand that new refresh_token back to the consumer of this package so that it's persisted for the next time the application starts?

[rbren]

All good questions! Thanks @theckman.

Even just having a function like refresh_token, err := refreshAccessToken(access_token, refresh_token) would be nice. There are also probably interesting ways to do an automatic refresh on 401, e.g. pass in a refreshTokenUpdate channel to the client. I wonder if there are other go client libs out there handling oauth

[dobs]

Clients doing their own token negotiation is often the "correct" way given that coordinating token lifecycle is normally outside the scope of the client itself.

Maybe providing documented examples leveraging oauth2 is a good starting point, either swapping pagerduty.Client's HTTPClient with config.Client's and/or using config.TokenSource? I can contribute some if they'd be useful.

We could also potentially provide some conveniences, e.g.:

• An oauth2.Config helper function.
• An oauth2.Endpoint value for folks doing their own config.
• A new variation of pagerduty.NewOAuthClient (NewManagedOAuthClient? NewAutoOAuthClient?) that automatically sets up and leverages an oauth2.Config, exposes it on pagerduty.Client.

Again some things I'd be happy to contribute if it's a direction we think is worth pursuing.

One minor detail is that we'll also be rolling out more OIDC functionality so a useful alternative to oauth2 might be go-oidc, but they mostly play nice together.