Add support for AAD v2 in adal package

[ccojocar]

I am creating this issue to collect your thoughts about AAD v2. The current implementation supports AAD v1, but would be nice to have some support for v2 which implements the OIDC specs.

https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-compare

I am not sure if there are any particularities in AAD v2, or one can use an exiting Go package such as https://github.com/coreos/go-oidc to acquire an id_token.

cc @colemickens @marstr

[colemickens]

I've found AADv2's OIDC support to be very straight forward -- for example, the OIDC plugin in kubectl was able to refresh id_tokens, etc with AADv2 out-of-the-box.

A (better) open source Golang OAuth2 client should be able to talk to AADv2 for OAuth. Since Azure stuff can't use AADv2, Go-Autorest and Azure SDK use our custom OAuth client. Hopefully stuff that is targeting AADv2 can use the popular community packages for OAuth/OIDC.

Not to say I'm opposed to having AADv2 support in here too, it just might not be worth it.

[ccojocar]

Thank you @colemickens, it's fair enough. I think the AADv2 implements the OAuth 2.0 on top of OIDC which I am not sure if is mainstream.

https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols-oauth-client-creds

The OIDC client will request access to a resource by passing the URL in a scope parameter among other things like permissions.

[colemickens]

Sure, OIDC flow is like OAuth2 but more standardized (endpoint discovery, etc). And requesting an id_token happens by requesting a specific scope... but any other resources included in the scope become part of the access token, not the id_token. In that sense, it's just a normal OAuth2 flow with an OIDC-capable/compliant endpoint.

If you look through the OIDC spec, it looks like OIDC == OAuth2 spec + id_token + endpoint discovery. Most of the major OAuth2 providers also implement OIDC (at the very least discovery, but many of them full fledged id_tokens, etc).

[jhendrixMSFT]

We are moving to AAD v2 as part of our track 2 SDK work. It will be handled via our azidentity module.

We won't be doing anything for track 1 in go-autorest so I'm closing this.

[colemickens]

@jhendrixMSFT I've bit a bit out of the Azure loop. Does this mean ARM accepts AADv2 tokens now? It didn't for the longest time? Thanks for any information, cheers!

[tombuildsstuff]

@jhendrixMSFT is there a timeframe for when Track1 will become end-of-life? Based on what I've seen of Track2 it appears we'll be unable to move to it unfortunately

[jhendrixMSFT]

@catalinaperalta can you answer the question @colemickens asked above?

@tombuildsstuff my POR is to have a preview of a handful of management plane modules ready this month. These are currently staged here if you'd like to take a look. I'd love to get your feedback although let's track any concerns in a new issue in the SDK repo. Also, the module import issue has been resolved in go-autorest, and now that we understand the root cause it won't be a problem for track 2.