Multitenant silent authentication fixes

[chlowell]

This fixes a couple bugs:

1. Silent auth defaults to the given account's tenant instead of the client's configured tenant.
2. Silent auth fails when the cache lacks an ID token from the requested tenant even though the cache contains a valid refresh token. My fix here is to have the cache return all the matching data it has instead of returning an error on the first miss. The caller is responsible for deciding whether the returned data is sufficient for its purpose.

[ellismg]

Thanks for fixing this @chlowell. I verified that it fixes my larger end to end scenario and thanks for taking my repo and turning it into a test.

FWIW - It looks like some of the option types have been renamed (and the signature of some public methods changed) which meant I had to do a little surgery both in the azidentity package and my code (which uses MSAL directly) to adopt the breaking changes. Not sure if you intend to roll the back on not.

Thanks again for your help here!

[ellismg]

Do you think there is value in still returning an error in the case where we fail to read some parts of TokenResponse to communicate to our caller that we were only able to do a partial read? In general, I know you shouldn't touch any of the other returned values when error is non nil, but I've seen some go APIs that document what values are correct when an error is returned - I imagine that we could say we could trust an non-zero part of the structure.

[ellismg]

I'm just worried that some consumer is going to call Read() in this state, fail to find an ID token, but since an error is not returned, they go ahead and party on the zero value of the ID Token and expect it to be something sensible.

[chlowell]

Sure, that's possible in principle, though I think zero values here are obviously invalid. Because this is an internal API, I don't mind trusting callers to continue following the convention of validating cache data before using it (see AuthResultFromStorage()). If that proves unworkable, I would rather decompose Read() into ReadAccessToken(), ReadIDToken(), etc. than ask callers to ignore irrelevant errors.

[bgavrilMS]

This fixes a couple bugs:

1. Silent auth defaults to the given account's tenant instead of the client's configured tenant.
2. Silent auth fails when the cache lacks an ID token from the requested tenant even though the cache contains a valid refresh token. My fix here is to have the cache return all the matching data it has instead of returning an error on the first miss. The caller is responsible for deciding whether the returned data is sufficient for its purpose.

1. If the app developers configures a tenanted authority (i.e. lmo/GUID), then AcquireTokenSilent should use that GUID.
2. When does this happen, i.e. when do you not find an IdTOken in the cache?

[chlowell]

when do you not find an IdTOken in the cache?

Whenever you silently authenticate a user in a new tenant e.g., authenticate a user in tenant A then silently authenticate that user in tenant B. The cache doesn't return an ID token in this scenario because it searches for one whose realm equals the requested tenant (here; realm argument is the requested tenant). I suppose that could be a bug? I left it as-is because it didn't seem obviously wrong--silent auth doesn't need the ID token.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
2 Code Smells

No Coverage information
0.0% Duplication