Bug 1986504

@milti a relogin should be sufficient. Are you creating those tokens in some automated way?

the issue is that, judging from the number of extant tokens [700+] in the cluster for the oauth-client, a relogin isnt doing the job. this is a user-managed oauthaccesstoken client that manages a workload in the cluster. what does the cu have to do to make the client produce tokens compliant to the new rule on names?

OTOH, oauthaccesstokens created by core cluster components ARE compliant w the new rule on the *sha~* prefix.

hello, is there any update on this issue? though the issue isnt critical now, the cu is concerned abt the warning and would like to eliminate it byt getting their user-managed oauthaccesstoken in compliance w the *sha~* prefix naming.

sprint review: due to other high priority work this wasn't been worked on.

mleonard - I'm not entirely sure I follow the use case. From my understanding:

- The customer uses OpenShift 4.7 and uses a custom OAuth Client. It would be helpful to check how that client looks like.
- The Custom OAuth Client is used by a 3rd party IdP. So effectively, when someone logs in, a new token is being created.
- Each user can view his own tokens by calling `oc get useroauthaccesstokens`

If my understanding is correct, I believe the customer should delete all non-sha-256 compatible tokens using this procedure: https://access.redhat.com/documentation/en-us/openshift_container_platform/4.7/html/authentication_and_authorization/managing-oauth-access-tokens#oauth-delete-tokens_managing-oauth-access-tokens. This will cause all the users to be logged out and new sha-256-compatible tokens should be created upon the new login.

Please let me know if this works for your client.

The new token naming convention has been described in https://github.com/openshift/enhancements/blob/master/enhancements/authentication/oauth-resource-storage.md#proposal:

> "sha256~" for new tokens. The name of the token objects is the sha256 hash of the actual token (not decoded, but plain base64) encoded as base64. The bearer token will also carry the prefix, but have the token in plain text.

also this part:

> Note: the tilde is a valid character in oauth tokens used as bearer tokens (according to RFC6750), and it works as character in URL paths. Colon, which we used in an earlier iteration of this enhancement is not valid for the former.

The Golang code that we use to construct such a name might be found here: https://github.com/openshift/oauth-server/blob/a51e18174ac32f0e44dfa8946e812d25ff38a101/pkg/server/crypto/sha256.go#L20:

```
func SHA256Token(token string) string {
  h := sha256.Sum256([]byte(token))
  return SHA256Prefix + base64.RawURLEncoding.EncodeToString(h[0:])
}
```

The sha256 is mentioned in two places in our public documentation:
- https://docs.openshift.com/container-platform/4.8/release_notes/ocp-4-8-release-notes.html#ocp-4-8-oauth-tokens
- https://docs.openshift.com/container-platform/4.8/authentication/managing-oauth-access-tokens.html#oauth-view-details-toke[…]ing-oauth-access-tokens

We will add additional REST api docs.

This bug is actively worked on.

Testing with 4.10.0-0.nightly-2021-10-07-212540, the statement 'The name of a token must be prefixed ...' added in code is not shown in the DESCRIPTION filed. Please help to double check.

$ oc explain oauthaccesstoken
KIND:     OAuthAccessToken
VERSION:  oauth.openshift.io/v1

DESCRIPTION:
     OAuthAccessToken describes an OAuth access token

FIELDS:
   apiVersion	<string>
     APIVersion defines the versioned schema of this representation of an
     object. Servers should convert recognized schemas to the latest internal
     value, and may reject unrecognized values. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

   authorizeToken	<string>
     AuthorizeToken contains the token that authorized this token

...

bump this in cluster-config-operator to finalize it.

reviewed-in-sprint: not enough capacity to work on this bugzilla.

correction: this needs to be bumped in oauth-apiserver

I’m adding UpcomingSprint, because I was occupied by fixing bugs with higher priority/severity, developing new features with higher priority, or developing new features to improve stability at a macro level. I will revisit this bug next sprint.

oc explain oauthaccesstoken
KIND:     OAuthAccessToken
VERSION:  oauth.openshift.io/v1

DESCRIPTION:
     OAuthAccessToken describes an OAuth access token. The name of a token must
     be prefixed with a `sha256~` string, must not contain "/" or "%!"(MISSING)
     characters and must be at least 32 characters long.

     The name of the token is constructed from the actual token by
     sha256-hashing it and using URL-safe unpadded base64-encoding (as described
     in RFC4648) on the hashed result.

     Compatibility level 1: Stable within a major release for a minimum of 12
     months or 3 minor releases (whichever is longer).


The description has been updated with
"OAuthAccessToken describes an OAuth access token. The name of a token must
     be prefixed with a `sha256~` string, must not contain "/" or "%!"(MISSING)
     characters and must be at least 32 characters long." in clusterversion 4.10.0-0.ci.test-2021-11-26-084725-ci-ln-qitlg1k-latest, hence, Verified

oc get clusterversion
NAME      VERSION                              AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.10.0-0.nightly-2022-01-24-070025   True        False         7h23m   Cluster version is 4.10.0-0.nightly-2022-01-24-070025

oc explain oauthaccesstoken

KIND:     OAuthAccessToken
VERSION:  oauth.openshift.io/v1

DESCRIPTION:
     OAuthAccessToken describes an OAuth access token. The name of a token must
     be prefixed with a `sha256~` string, must not contain "/" or "%!"(MISSING)
     characters and must be at least 32 characters long.

     The name of the token is constructed from the actual token by
     sha256-hashing it and using URL-safe unpadded base64-encoding (as described
     in RFC4648) on the hashed result.

     Compatibility level 1: Stable within a major release for a minimum of 12
     months or 3 minor releases (whichever is longer).

Which contains

"%!"(MISSING)

Still facing the issue mentioned in Comment 22, reassigning

This change hasn't been pulled so far. @

Maciej Szulik will know when this gets merged.

It works correctly in 4.10.3:

$ oc version
Client Version: 4.10.3
Server Version: 4.10.3
Kubernetes Version: v1.23.3+e419edf

$ oc explain oauthaccesstoken
KIND:     OAuthAccessToken
VERSION:  oauth.openshift.io/v1

DESCRIPTION:
     OAuthAccessToken describes an OAuth access token. The name of a token must
     be prefixed with a `sha256~` string, must not contain "/" or "%" characters
     and must be at least 32 characters long.
[...]

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days