New command: cli accesstoken refresh

[milanholemans]

Usage

m365 cli accesstoken refresh

Description

Refreshes all cached access tokens

Options

Option	Description
-r, --resource [resource]	Refresh only a specific access token from a specific resource. By default, all tokens are refreshed.

Examples

Refreshes all cached access tokens

m365 cli app accesstoken refresh

Refresh only a SharePoint access token

m365 cli app accesstoken refresh --resource sharepoint

Default properties

No response

Additional Info

Just like we do for util accesstoken get, let's support sharepoint and graph as resources.

---

Where does this idea come from? In the past, I've been fiddling with access tokens quite a lot. Adding and removing access tokens from the app registration to check whether or not I have enough permissions to perform a specific action. This is not so easy since an acquired access token remains valid for one hour by default, and these tokens are used by CLI until they expire. The only solution is, logging out and back in again, or using util accesstoken get -r sharepoint --new for example. While the last method is easy for Graph and SharePoint (the most common resources), it becomes harder for other APIs since their resource name is not that common anymore.

After creating command #6657, it's cool that we can now update the app registration to run all commands in CLI, but we suffer again from the same cached access token issue. Therefore, I suggest that we create a command that refreshes all, or a specific access token, to make things easier.

I suggest that command #6657 should also reference this new command so people are not scratching their heads as to why their new permission scope is not working.

[waldekmastykarz]

The only solution is, logging out and back in again, or using util accesstoken get -r sharepoint --new for example. While the last method is easy for Graph and SharePoint (the most common resources), it becomes harder for other APIs since their resource name is not that common anymore.

How does the new command address this problem? Is it, because it allows you to refresh all access tokens?

m365 cli app accesstoken refresh

I think it's confusing to have 2 access token-related commands in two different namespaces. My gut feeling tells me that it would make sense to consolidate them under m365 cli accesstoken <verb>, since the purpose of the commands is to work with CLI's access tokens.

[milanholemans]

How does the new command address this problem? Is it, because it allows you to refresh all access tokens?

Yes, just like when you use m365 util accesstoken get --ressource sharepoint --new, the command should grab a new access token (that would include the newly consented scope) and store it locally. The difference is that this command will do it for all cached access tokens instead of only one. By running this command, you are guaranteed that all cached access tokens contain the latest scopes from the app registration.

I think it's confusing to have 2 access token-related commands in two different namespaces. My gut feeling tells me that it would make sense to consolidate them under m365 cli accesstoken , since the purpose of the commands is to work with CLI's access tokens.

Does this mean that you want to move util accesstoken get under cli accesstoken?

[waldekmastykarz]

By running this command, you are guaranteed that all cached access tokens contain the latest scopes from the app registration.

That's not quite true. The token will get the latest tokens from the service principal. If you've updated the app reg, but haven't reconsented, you'll still miss the latest addition.

Does this mean that you want to move util accesstoken get under cli accesstoken?

If we decide to build this new command, then I suggest we consider it. We can of course do it gradually with an alias+deprecation first and removal in the next major.

[milanholemans]

That's not quite true. The token will get the latest tokens from the service principal. If you've updated the app reg, but haven't reconsented, you'll still miss the latest addition.

Yes, that's true, but that's the responsibility of the user in my opinion.

[martinlingstuyl]

@milanholemans i like the idea and I also support the idea of moving both to the CLI command group.

One thing: if I'm using refresh for a specific resource, that does the same as using --new on the existing get command. That's not a problem perse though. But what's the difference? Why would you use get --new over refresh --resource?

[waldekmastykarz]

Yes, that's true, but that's the responsibility of the user in my opinion.

Correct, but we need to clearly manage the expectations that at the end of the day we depend on what's on the service principal, not app reg, so we can't magically return all scopes if they haven't been consented first 😅

One thing: if I'm using refresh for a specific resource, that does the same as using --new on the existing get command. That's not a problem perse though. But what's the difference? Why would you use get --new over refresh --resource?

They're identical. The only difference is, that refresh can refresh all tokens at once, while get --new only does one at a time.

[milanholemans]

I think @martinlingstuyl questions what the difference would be between util accesstoken get --resource sharepoint --new and cli accesstoken refresh --resource sharepoint. In that case, there won't be much difference. But I would expect the latter approach to be a bit more straightforward for someone who wants to refresh just one specific token instead of everything.

[waldekmastykarz]

One more idea... going back to the reason behind this proposal:

I've been fiddling with access tokens quite a lot. Adding and removing access tokens from the app registration to check whether or not I have enough permissions to perform a specific action. This is not so easy since an acquired access token remains valid for one hour by default, and these tokens are used by CLI until they expire. The only solution is, logging out and back in again

So it's not about access tokens, it's about auth. So should this command be named m365 cli auth refresh? Alternatively, we could also do m365 login --refresh. Thoughts?

[martinlingstuyl]

Good point waldek, we also have a login --ensure variant. It does not do the same thing, but I wonder if it would be too complicated or vague to have login --refresh as well as login --ensure on the login command.

We could also add it on the connection command: m365 connection refresh. I'm not sure about that though, as those commands are primarily targeted at the multi account idea...

[milanholemans]

I'm not really a fan of m365 login --refresh to be honest. It's not really clear what it does in my opinion. And like Martin mentioned, it can become complicated with --ensure already beeing there.
m365 connection refresh is also weird since it has nothing to do with multi account management.
In my opinion all CLI related stuff should go under cli.

[Jwaegebaert]

Yeah, this would definitely be a useful command. I was testing some of our SPE commands and tweaking my app reg, and having a quick way to refresh all tokens after adding scopes would’ve come in handy.

+1 for keeping it in the cli group, feels like the right spot. As for the name, I like auth, but accesstoken lines up better with what we already have like util accesstoken get. Since we’re specifically refreshing the access token, that might be the more accurate fit.