token
An opaque Bearer token that clients should supply to subsequent
requests in the Authorization header.
access_token
For compatibility with OAuth 2.0, we will also accept token under
the name access_token. At least one of these fields must be
specified, but both may also appear (for compatibility with older
clients). When both are specified, they should be equivalent; if
they differ the client's choice is undefined.
All other fields are optional whereas at least one of token or
access_token has to be present and they have to be same if both are.
So I think an easy fix would be as demonstrated in attached patch,
though it doesn't touch unit tests at all.
Also quoting from https:/ /docs.docker. com/registry/ spec/auth/ token/
token
An opaque Bearer token that clients should supply to subsequent
requests in the Authorization header.
access_token
For compatibility with OAuth 2.0, we will also accept token under
the name access_token. At least one of these fields must be
specified, but both may also appear (for compatibility with older
clients). When both are specified, they should be equivalent; if
they differ the client's choice is undefined.
All other fields are optional whereas at least one of token or
access_token has to be present and they have to be same if both are.
So I think an easy fix would be as demonstrated in attached patch,
though it doesn't touch unit tests at all.