This looks like a net/http wrapper. Kubernetes already has a ton of these in tree. Is this required?

It is required. This is the base of the azure sdk, which contains the authentication package which is used by this plugin.

Are there some docs on what the technical details of this flow? That'd be very helpful when reviewing this PR. e.g. why a user would prefer this over the OpenID Connect client auth plugin.

Unfortunately I couldn't find some reasonable documentation for this flow. The big difference between client credentials and device code flows is that the JWT token acquired with the former one contains user information. It is a user token not a client token. The claims form this token can be used later for role-based access control.

This flow is suited for CLI tools. e.g. Azure CLI makes use of it in order to acquire user tokens.

It should be roughly this extension: https://tools.ietf.org/html/draft-ietf-oauth-device-flow-05

Anyway, doesn't Google do something similar with a gcloud specific plugin?

In Azure's case, the actual id_tokens produced by AADv1 (at least after refresh) are not signed and thus not usable for this scenario. Hence the use of the access_token presumably - but again, that's the same thing the Google plugin does when it reads the access token from the json response from gcloud config config-helper.

Google's GCP plugin signs a JWT but the format is somewhat propitiatory to GCP. They use webhook auth to process the token on their end, they don't use the OpenID Connect plugin.

Right, I forgot I learned that a couple weeks ago...

is DEC7D48GA just an example?

This is fake code number.

Is this prompt triggered by kubectl directly? What happens if it's not in an interactive session? I'd expect these kind of flows to be handled by az login

There are two scenarios:

1. The user logs in with az login which stores the tokens in ~/.azure/accessToken.json file. The azure plugin will read the tokens from this file and refresh them if needed using the client_id also from the same file.

2. If the plugin does not find any az file available. It will start the device flow by prompting to the use the device code retrieved from AAD and waiting for use to login. The user will login with AAD in a browser by providing the device code. Finally the plugin will receive the tokens directly from AAD.

Note that in both cases the tokens are stored in the kubernetes configuration. Next time when the kubectl is executed, it will read the token from kubernetes config first.

typo: Teant

typo: clinet

Should this also be parameterized as "APPLICATION_ID" in case the user chooses to use a different client_id below? Otherwise how does the token validation work?

Apparently the apiserver expects the client id to be the same like the audience. Actually apiserver which plays the role of a resource server does not need a valid client id. It only has to download the public keys of the identity provider in order to verify the signature of the token.

Does azure embed this as the audience? Isn't that claim supposed to be set as the client-id?

The audience should be different than the client ID. The audience is typically a URI of a rest-endpoint or a UUID.

I guess the clean fix is to have two options, one for client id and other one for audience. The appiserver should verify the audience from the token against the whitelisted value provided in the option.

The audience should be different than the client ID.

Why do you say this? That's not my understanding or expectation. With real id_token, the audience is the client_id. See: https://github.com/colemickens/azure-ad-k8s-oidc-example

(and even though that example is AADv2, the same is true of id_tokens issued to AADv1). The example works as normal, with normal client_id (not the resource value), etc.

Let's take an example. I have a resource application registered with AAD for apiserver which has the resourceAppId fdfb78c2-788c-4ab6-bbed-cfd89cd21025. This will be provided in the --oidc-client-id. Now if I need to acquire a token for this application, another client application must be registered wiht appId 319e3b43-c214-43e8-8d8d-8d33b8e47902 which has delegated permissions to the apiserver application.

I can request a token with the following values:

• applicatoinId: 319e3b43-c214-43e8-8d8d-8d33b8e47902
• tenantId:
• resource: fdfb78c2-788c-4ab6-bbed-cfd89cd21025

The returned token will have these claims (many claims ignored for brevity):

{
"aud": "spn:fdfb78c2-788c-4ab6-bbed-cfd89cd21025",
 "iss": "https://sts.windows.net/26f087ba-1a21-11e7-93ae-92361f002671/",
 "appid": "319e3b43-c214-43e8-8d8d-8d33b8e47902"
}

azure cli does the same but the audience is an URL:

{
"aud": "https://management.core.windows.net/",
 "iss": "https://sts.windows.net/72f988bf-86f1-41af-91ab-2d7cd011db47/",
  "appid": "04b07795-8ddb-461a-bbee-02f9e1bf7b46"
}

As you see from the first example the audience can be almost the same like the client id if one uses the UUID of the resource when acquiring the token.

Note that any owner of an application can set delegated permissions to any public resource application registered in the same AAD. The conclusion is that the RBAC policy should be based on the user and group claims. The audience does not have strong security guarantees.

The audience should be different than the client ID.

No, this is totally against the OpenID Connect spec[0]

[0] https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation

I get you point a client needs to request a token for itself. In that case AAD will return:

{
  "aud": "spn:319e3b43-c214-43e8-8d8d-8d33b8e47902",
  "iss": "https://sts.windows.net/72f988bf-86f1-41af-91ab-2d7cd011db47/",
   "appid": "319e3b43-c214-43e8-8d8d-8d33b8e47902",
}

Are you fine if the oidc-id is configured to spn:319e3b43-c214-43e8-8d8d-8d33b8e479021?

@ericchiang @colemickens
I guess, the azure cli integration has to be removed because it adhere to OAuth2 actors model (http://nordicapis.com/api-security-oauth-openid-connect-depth/) requesting always a token for a resource server not for itself.

I can keep the device code and also remove the audience configuration.

typo: audiance

@colemickens Thank you for review! I fixed the typos.

Am I right in understanding this is using an accessToken as an OIDC token?

My understanding is that this was discouraged: https://oauth.net/articles/authentication/

But I think the Google auth works this same way, by taking the CLI access token and using it as an OIDC token...

cc: @ericchiang can you share any thoughts on this too?

In AAD the access token is equivalent with id token. It is a JWT token with all claims of a user.

I guess I'm still pretty confused as to how this conforms to OIDC, or is secure in its usage. To be clear, as far as I can tell, it seems to be the same pattern that Google uses... but it seems invalid with my understanding of OIDC.

Consider: If the client_id is not validated, and any old access token can be used, it means that I can take accessTokens granted to me via any application and then use them to talk to your apiserver? That seems... potentially very bad. Or am I misunderstanding? Doesn't this mean my personal application that lets users do OAuth flow to let me create some things in their subscription... can't I now turn around and use those scoped access tokens to get access to some disparate Kubernetes clusters that just happen to be configured for the same tenant without the user's consent?

This is sort of the scenario discussed in the link above that discourages the use of accessTokens for AuthN...

Consider: If the client_id is not validated, and any old access token can be used, it means that I can take accessTokens granted to me via any application and then use them to talk to your apiserver? That seems... potentially very bad.

Yes, it is extremely weird that the oidc-client-id is not set to a unique client_id.

Why can't we just use the id_token directly?

AADv1 doesn't sign id_token when they're refreshed - meaning user would have to do device auth every hour - regardless of if kubectl was retrieving directly, or if we forced user back to az.

AADv2 lacks this entire device flow.

This is right the id_token issued by AAD cannot be used to verity the access, but as I said the access token contains the same claims.

It is a bit strange how the appiserver validates the audience. The identity provider will request consent to a user for a specific audience when issuing the token. In this case should be a dedicated audience for kubernetes apiserver which should be registered in the identity provider as resource server.

The issue is in CorsOS's go-oidc package which is used by the oidc plugin of apiserver. It property verifies the signature, expiration but it does the following assumption on audience.

https://github.com/coreos/go-oidc/blob/master/oidc/verification.go

Code snippet from VerifyClaims function

	// aud REQUIRED. Audience(s) that this ID Token is intended for.
	// It MUST contain the OAuth 2.0 client_id of the Relying Party as an audience value.
	// It MAY also contain identifiers for other audiences. In the general case, the aud
	// value is an array of case sensitive strings. In the common special case when there
	// is one audience, the aud value MAY be a single case sensitive string.
	if aud, ok, err := claims.StringClaim("aud"); err == nil && ok {
		if aud != clientID {
			return fmt.Errorf("invalid claims, 'aud' claim and 'client_id' do not match, aud=%s, client_id=%s", aud, clientID)
		}
	} else if aud, ok, err := claims.StringsClaim("aud"); err == nil && ok {
		if !containsString(clientID, aud) {
			return fmt.Errorf("invalid claims, cannot find 'client_id' in 'aud' claim, aud=%v, client_id=%s", aud, clientID)
		}
	} else {
		return errors.New("invalid claim value: 'aud' is required, and should be either string or string array")
	}

@cosmincojocar the audience shouldn't be the API server, it should be whatever the client_id of the client that initiated the login flow to request an ID token. That's specifically called out in the docs. The API server is NOT a client. It's set up to only allow ID tokens issues for a single client.

As for that snippet, it's just implementing the spec[0]

3. The Client MUST validate that the aud (audience) Claim contains its client_id value registered at the Issuer identified by the iss (issuer) Claim as an audience. The aud (audience) Claim MAY contain an array with more than one element. The ID Token MUST be rejected if the ID Token does not list the Client as a valid audience, or if it contains additional audiences not trusted by the Client.

The issue seems to be the aud embedded in your access token, which is https://management.core.windows.net/ rather then your client_id.

[0] https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation

Can you not hard code this? This will fail in Germany/China clouds.

You have the real (full tenant) authority URL in the tokens json anyway, I believe.

I removed the hardcoded authority URL. It is read anyhow from file. Also the Azure environment is now configurable for device code flow.

Anyway, doesn't Google do something similar with a gcloud specific plugin?

In Azure's case, the actual id_tokens produced by AADv1 (at least after refresh) are not signed and thus not usable for this scenario. Hence the use of the access_token presumably - but again, that's the same thing the Google plugin does when it reads the access token from the json response from gcloud config config-helper.

I guess I'm still pretty confused as to how this conforms to OIDC, or is secure in its usage. To be clear, as far as I can tell, it seems to be the same pattern that Google uses... but it seems invalid with my understanding of OIDC.

Consider: If the client_id is not validated, and any old access token can be used, it means that I can take accessTokens granted to me via any application and then use them to talk to your apiserver? That seems... potentially very bad. Or am I misunderstanding? Doesn't this mean my personal application that lets users do OAuth flow to let me create some things in their subscription... can't I now turn around and use those scoped access tokens to get access to some disparate Kubernetes clusters that just happen to be configured for the same tenant without the user's consent?

This is sort of the scenario discussed in the link above that discourages the use of accessTokens for AuthN...