Introduce @me.id and @me.userName to simplify working with the current user

[waldekmastykarz]

We have commands that require you to specify the user's ID or name. Currently, there's no way to easily specify information about the current user. There are some workarounds like retrieve the user name from the status command. If you need user's ID you'd pass the name to the aad user get command. We could also consider custom implementations in the different commands to introduce specific options like --me. But this is all too cumbersome.

Since we have information about the current user already available in the access token, we could introduce tokens like @me.id and @me.userName that we'd replace with the corresponding information, similarly like we pass content from files. This would free us from having to have command-specific implementations and would make it easier to work with data specific to the current user.

What do you think @pnp/cli-for-microsoft-365-maintainers?

[appieschot]

Yes, something would be of added value for me 🦾

[plamber]

@waldekmastykarz: this will certainly help.

I would also extend the status and add the id to the result, not only the upn as we do today

How do we handle app only applications? Are we just returning undefined in these cases?

[waldekmastykarz]

For app-only auth we show the app's name. We could absolutely expose the ID in the status command. The ID is stored in the oid property in the token.

[waldekmastykarz]

So the question is should @me tokens be only for delegated-auth and return an empty string for app-only to ensure that we won't end up passing appId as user ID into a command?

[plamber]

I believe @me tokens should be delegated tokens only to avoid passing wrong ids to commands.

Naturally, you could state that me could be the appid. But at first glance it feels more natural to associate it with me as a logged in user

[waldekmastykarz]

Makes sense. If need be, we can always introduce more tokens, specific to app-only auth