Multi-account support implementation

[ifitzpat]

Hi @harishkrupo,

Thanks for your efforts in this project! I see multi-account support is one of the TODO's and I'm willing to lend a hand if needed. I had some thoughts on how to implement this that I'd like to run by you. Would it be an option to:

• Add an optional command line parameter (e.g., --account user@example.com)
• Set credentials file to whatever is passed under account (e.g., save_data_path("oauth2ms") + "/" + cmdline_args.account)

I'm not sure how this would work with the credentials cache or indeed if anything else would break. What's your take?

[harishkrupo]

I see multi-account support is one of the TODO's and I'm willing to lend a hand if needed.

Yes, this has been on my bucket for a long time and would certainly appreciate the help :)

Add an optional command line parameter (e.g., --account user@example.com)

If the clients belong to different tenants then we will require a completely different set of configuration options (different config.json files). We have two options here:

• Create one config file but with different keys in the json object:

  {
      "user1@example.com" : { "client_id" : "", "tenant_id": "", ...}
      "user2@anotherexample.com :  { "client_id" : "", "tenant_id": "", ...}
  }

• Create different file for each config and add an optional --config config_file_name parameter. The configuration file would then be searched as $XDG_CONFIG_HOME/oauth2ms/config_<config_file_name>.json

IMO option 2 seems like a cleaner solution since option 1 would break backwards compatibility with the current config file format

Set credentials file to whatever is passed under account (e.g., save_data_path("oauth2ms") + "/" + cmdline_args.account)

Now, we can just reuse the --config parameter when creating the cache file. The cache file would then be named as save_data_path("oauth2ms") + "/credentials" + "_<config_file_name>" + ".bin". This way we can reuse the existing code. Additionally, people who don't require multi-account support won't need to change anything.

[harishkrupo]

Okay, this turned out to be simpler than I had expected.
Changes Needed:

• Delete this line: https://github.com/harishkrupo/oauth2ms/blob/main/oauth2ms#L39
• Add a new parser for --config command line argument here: https://github.com/harishkrupo/oauth2ms/blob/main/oauth2ms#L55
• Add the following after line https://github.com/harishkrupo/oauth2ms/blob/main/oauth2ms#L56:

config_file_name = "config.json"
credentials_file_name = "credentials.bin"
if cmdline_args.config is not None:
    config_file_name = "config_" + cmdline_args.config + ".json"
    credentials_file_name = "credentials_" + cmdline_args.config + ".json"

• Remove hardcoded file name from line: https://github.com/harishkrupo/oauth2ms/blob/main/oauth2ms#L60

Hopefully I have not missed anything. This should ensure that the rest of the code remains the same. Let me know if you are interested in opening a PR :)

[ifitzpat]

I'm certainly willing to do the pull request! One thing I'm wondering about. Is it necessary to have separate configurations for different accounts? Wouldn't the app work across tenants?

[harishkrupo]

Wouldn't the app work across tenants?

This was my initial doubt too, and the main reason I was postponing this TODO. However, if you look at the details of the app in azure portal, it shows the client ID along with tenant ID. To me, this seems like the app is tied to the tenant, but I could be wrong. You are welcome to investigate further on this :) If you find that one app can support multiple tenants, great! We can discuss and change the design. Otherwise, we have the current design to fallback on.

[ifitzpat]

👍🏼 I'll do some testing

[iinuwa]

This was my initial doubt too, and the main reason I was postponing this TODO. However, if you look at the details of the app in azure portal, it shows the client ID along with tenant ID. To me, this seems like the app is tied to the tenant, but I could be wrong. You are welcome to investigate further on this :) If you find that one app can support multiple tenants, great! We can discuss and change the design. Otherwise, we have the current design to fallback on.

This can be circumvented by creating a Microsoft account and registering a multi-tenant application yourself as the developer. Then you can hard-code in the tenant as "/common, as well as a pre-generated client ID and secret. Then, you can configure the app to use authorization code + PKCE flow to authenticate.

This will help users that don't have the ability to register applications in their tenant; they can just use the multi-tenant one that's already created.

For an example of how this works, compare with FairEmail: https://github.com/M66B/FairEmail/blob/592ded9470fcab0cc205e17fbd21ea09c82c31f0/app/src/main/res/xml/providers.xml#L79-L103

[gavinschenk]

This #8 is hanging around for some time now.
It looks promising to support more than one account on a tenant, if this is the use case....

My use case is separating private mail from work mail and I like to separate this strict and therefore love the --config approach discussed earlier #7 (comment) .

I think this would be a solid base to implement the ACCOUNT feature on top of it, as a second step?!

What is your advise?

[gavinschenk]

This is my working state #26 . What do you think?