OIDC integration (id_token vs access_token)

[ysob...@ashland.edu]

Why OIDC integration only accepts id_token, but not the access_token?

“…To identify the user, the authenticator uses the id_token (not the access_token) from the OAuth2 token response as a bearer token….”

https://kubernetes.io/docs/reference/access-authn-authz/authentication/

Source code: https://github.com/kubernetes/kubernetes/blob/ea92879fab9eb9cd7a2529101fb088c2f07bd547/staging/src/k8s.io/client-go/plugin/pkg/client/auth/oidc/oidc.go

--oidc-groups-prefix - Prefix prepended to group claims to prevent clashes with existing names (such as system: groups).
For example, the value oidc: will create group names like oidc:engineering and oidc:infra.

id_token should only be used for authentication

access_token should be used for authorization

However, I8 API server expects group claim to be part of id_token

[Jordan Liggitt]

The kubernetes API server is acting as a relying party with respect to the OIDC issuer, and is using the identity information in the id_token to determine the identity of the caller for authentication purposes. Group membership is part of the authentication layer.

Additionally, access tokens are opaque to relying parties... they are not required to be JWTs, and their contents are not standardized or guaranteed to contain inspectable claims.

--

You received this message because you are subscribed to the Google Groups "kubernetes-sig-auth" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-...@googlegroups.com.

To post to this group, send email to kubernete...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-auth/290ab5ca-5f69-4870-8145-fb664a4db44c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[ysob...@ashland.edu]

Will Kubernetes API server accept access_token instead of id_token?

I have OAuth2 provider that can only pass group in access_token

[Jordan Liggitt]

The API server will accept a JWT issued by the proper issuer, signed with valid signing keys, with proper audience, subject, and group claims.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-auth" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-...@googlegroups.com.
To post to this group, send email to kubernete...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-auth/fbbd7760-8666-4234-87a6-7db50158338f%40googlegroups.com.

[Praveen D]

Which OIDC provider are you using?
access-token is used azure, google. https://github.com/kubernetes/kubernetes/search?q=access-token&unscoped_q=access-token

My personal observation is kubectl uses access-token with AzureAD and id-token with CoreOS Dex.

Best Regards,

Praveen Darshanam

[Eric Chiang]

> My personal observation is kubectl uses access-token with AzureAD and id-token with CoreOS Dex.

AzureAD access tokens are JWTs that conform to the ID Token spec.[1] Like Jordan was saying, the API server validates JWTs with the correct structure and public key endpoints.

Access tokens are (by definition) opaque to the client though, and kubectl only uses AzureAD access tokens because the Azure team guaranteed this behavior. I'd be surprised if access tokens from any other provider worked, and even if they did it's within the provider's right to break you.

[1] http://openid.net/specs/openid-connect-core-1_0.html#IDToken

Eric 

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-auth" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-...@googlegroups.com.
To post to this group, send email to kubernete...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-auth/75daba12-fe60-4915-b67a-159c54ec84e5%40googlegroups.com.

[Yakov Sobolev]

Thanks Eric,

I tried to use access_token instead of id_token from ADFS provide, but it did not work.

:(

Is there a way to debug it in Kube API server?

kubectl --kubeconfig=config-demo get pods
error: You must be logged in to the server (Unauthorized)

I wonder why Azure access tokens work.

O am not sure why IDA insists that id token should not include roles. I’ve read OIDC documentation and articles and it can be done:
http://openid.net/specs/openid-connect-core-1_0.html#AdditionalClaims

“…OpenID providers may extend the standard JSON claims schema to include additional attributes. Enterprises may for instance define claims such as employee role, manager, and department. The names of any additional claims should be prefixed by a URL to create a safe namespace for them and prevent collisions. “
https://connect2id.com/learn/openid-connect

Microsoft Azure AD support groups and roles claims in id_token - https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-id-and-access-tokens

“groups - Groups - Provides object IDs that represent the subject's group memberships. These values are unique (see Object ID) and can be safely used for managing access, such as enforcing authorization to access a resource. The groups included in the groups claim are configured on a per-application basis, through the "groupMembershipClaims" property of the application manifest. A value of null will exclude all groups, a value of "SecurityGroup" will include only Active Directory Security Group memberships, and a value of "All" will include both Security Groups and Office 365 Distribution Lists. “

“roles - Roles - Represents all application roles that the subject has been granted both directly and indirectly through group membership and can be used to enforce role-based access control. Application roles are defined on a per-application basis, through the appRoles property of the application manifest. The value property of each application role is the value that appears in the roles claim

Examples:
https://connect2id.com/blog/using-openid-connect-to-make-assertions-about-end-users

Keycloack - You can opt to include or exclude the claim from both the id and access tokens by fiddling with the Add to ID token and Add to access token switches.
https://www.keycloak.org/docs/latest/server_admin/index.html#_mappers

Google Firebase:
https://firebase.google.com/docs/auth/admin/custom-claims

[Eric Chiang]

> I tried to use access_token instead of id_token from ADFS provide, but it did not work.

Can you just use the id_token?

> Is there a way to debug it in Kube API server?

You'll need logs from the API server, not just kubectl. You can increase the verbosity using the '--v=' flag if nothing's showing up.

> I am not sure why IDA insists that id token should not include roles.

You'll have to ask Azure :)

Eric

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-auth" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-...@googlegroups.com.
To post to this group, send email to kubernete...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-auth/6bdf09ae-eb0b-41c0-b690-1aaa3ae5f80d%40googlegroups.com.