Token Response Fields and Example Request

The name of the service which hosts the resource. #### `offline_token` Whether to return a refresh token along with the bearer token. A refresh token is capable of getting additional bearer tokens for the same subject with different scopes. The refresh token does not have an expiration and should be considered completely opaque to the client. #### `client_id` String identifying the client. This `client_id` does not need to be registered with the authorization server but should be set to a meaningful value in order to allow auditing keys created by unregistered clients. Accepted syntax is defined in [RFC6749 Appendix A.1](https://tools.ietf.org/html/rfc6749#appendix-A.1). #### `scope` The resource in question, formatted as one of the space-delimited entries from the `scope` parameters from the `WWW-Authenticate` header shown previously. This query parameter should be specified multiple times if there is more than one `scope` entry from the `WWW-Authenticate` header. The previous example would be specified as: `scope=repository:samalba/my-app:push`. The scope field may be empty to request a refresh token without providing any resource permissions to the returned bearer token. ### Token response fields #### `token` An opaque `Bearer` token that clients should supply to subsequent requests in the `Authorization` header. #### `access_token` For compatibility with OAuth 2.0, the `token` under the name `access_token` is also accepted. 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. #### `expires_in` (Optional) The duration in seconds since the token was issued that it will remain valid. When omitted, this defaults to 60 seconds. For compatibility with older clients, a token should never be returned with less than 60 seconds to live. #### `issued_at` (Optional) The [RFC3339](https://www.ietf.org/rfc/rfc3339.txt)-serialized UTC standard time at which a given token was issued. If `issued_at` is omitted, the expiration is from when the token exchange completed. #### `refresh_token` (Optional) Token which can be used to get additional access tokens for the same subject with different scopes. This token should be kept secure by the client and only sent to the authorization server which issues bearer tokens. This field will only be set when `offline_token=true` is provided in the request. ### Example For this example, the client makes an HTTP GET request to the following URL: ```text https://auth.docker.io/token?service=registry.docker.io&scope=repository:samalba/my-app:pull,push ``` The token server should first attempt to authenticate the client using any authentication credentials provided with the request. From Docker 1.11 the Docker Engine supports both Basic Authentication and OAuth2 for getting tokens. Docker 1.10 and before, the registry client in the Docker Engine only supports Basic Authentication. If an attempt to authenticate to the token server fails, the token server should return a `401 Unauthorized` response indicating that the provided credentials are invalid. Whether the token server requires authentication is up to the policy of that access control provider. Some requests may require authentication to determine

This section describes the fields in the token response, including `token` (or `access_token`), `expires_in`, `issued_at`, and `refresh_token`. It also provides an example HTTP GET request to the token endpoint. The response includes an explanation of how the token server authenticates the client and what to do if authentication fails, noting the Docker Engine's support for Basic Authentication and OAuth2 for getting tokens, with older versions only supporting Basic Authentication.