New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

well-known-uri-ref-engine-discovery: Drop 'auth*' params from the Docker example #64

Open

wking wants to merge 1 commit into xiekeyang:master from wking:docker-auth-uri

Commits on Jan 26, 2018

well-known-uri-ref-engine-discovery: Drop 'auth*' params from the Doc…

…ker example

Docker registries should include both of these in their
WWW-Authenticate response [1], and Docker's registry does:

  $ curl -I -H 'Accept: application/vnd.docker.distribution.manifest.v2+json' https://index.docker.io/v2/library/docker/manifests/1.12.1
  HTTP/1.1 401 Unauthorized
  Content-Type: application/json; charset=utf-8
  Docker-Distribution-Api-Version: registry/2.0
  Www-Authenticate: Bearer realm="https://auth.docker.io/token",service="registry.docker.io",scope="repository:library/docker:pull"
  Date: Fri, 26 Jan 2018 04:58:02 GMT
  Content-Length: 157
  Strict-Transport-Security: max-age=31536000

The WWW-Authenticate header is specified in RFC 7235 [2], and the
Bearer token is specified in RFC 6750 [3].  RFC 7235 defines realm and
allows for per-scheme extensions [4]:

  The realm value is a string, generally assigned by the origin
  server, that can have additional semantics specific to the
  authentication scheme.

But RFC 6750 has nothing to say about its semantics, so interpreting
it as the auth-server URI seems to be a Dockerism.  Similarly, the
service parameter seems to be a Dockerism, with no mentions of
'service' in RFC 6750.  'scope' is covered in RFC 6750 [5], which
delegates the definition to RFC 6749 [6].

RFC 6749 covers supplying the scope to the auth-server as a query
parameter [7].  It also covers client_id, which Docker also mentions
[8].  RFC 6749 requires auth-requests to include response_type=code
[7], which Docker does not mention [8]; but Docker accepts the RFC
value.

  $ curl -s 'https://auth.docker.io/token?response_type=code&client_id=testing&service=registry.docker.io&scope=repository:library/docker:pull' | jq -S .
  {
    "access_token": "...",
    "expires_in": 300,
    "issued_at": "2018-01-26T05:35:56.860615325Z",
    "token": "..."
  }

Docker does not seem to implement RFC 6749's recommended 'state'
parameter [7].

With both "use 'realm' as the auth server" and "pass through 'service'
as an auth query parameter" as Dockerisms, the RFCs are not sufficient
in themselves to specify Docker's current auth protocol.  These are
not vanilla bearer tokens.  But the information we previously supplied
via authUri and authService *is* in the intial resource response, so
we can stop supplying those ourselves.

[1]: https://github.com/docker/distribution/blob/v2.6.2/docs/spec/auth/token.md#how-to-authenticate
[2]: https://tools.ietf.org/html/rfc7235#section-4.1
[3]: https://tools.ietf.org/html/rfc6750
[4]: https://tools.ietf.org/html/rfc7235#section-2.2
[5]: https://tools.ietf.org/html/rfc6750#section-3
[6]: https://tools.ietf.org/html/rfc6749#section-3.3
[7]: https://tools.ietf.org/html/rfc6749#section-4.1.1
[8]: https://github.com/docker/distribution/blob/v2.6.2/docs/spec/auth/token.md#requesting-a-token

Signed-off-by: W. Trevor King <wking@tremily.us>

wking committed Jan 26, 2018